Unprivileged users are users who have:
-
Statically served web pages.
-
No server scripting language (PHP, ASP, JSP, Python etc.) available.
-
No custom CGI hosting. The only CGI they have available are globally shared Perl scripts for e-mail routines and such.
-
No way to configure their web server (either in the MMC console of IIS, or with .htaccess files in Apache).
-
No good way of notifying web server administrators of their needs, so they can fix the problem for them.
-
Web server administrators which are really lazy with upgrading, and don't really care whether the web server software is one, two, three or even four years old. «If it works, don't fix it.»
These users are mostly hosted by free web hosting services, most likely associated with their ISP.
If you change perspective on this list, and look at it as prerequisites to levels of Atom usage, it looks something like this:
To host an Atom feed and Atom-format entries, your ISP and/or publishing software must provide:
-
the ability to associate a MediaType with a file extension, or
-
the ability to deliver a Content-Type for Atom-format resources
To host a publishing system that supports the Atom API, your ISP and/or publishing software must provide:
-
the ability to run CGIs or server modules (depending on the combination of server and available publishing software combinations)
-
the ability to send and receive HTTP headers.
-
for binary HTTP content, the ability to handle PUT and DELETE requests.
A related survey of incomplete implementations of HTTP can be found at CarrotVsOrange, which lead to DifferentlyAbledClients, which in turn was the motivation for the SOAP Enabling section of the draft-gregorio-09 version of the AtomAPI. PaceWsdl continues this work; PaceAtomActionHeader has been forward as an alternative.