$Web\xdeing$

CGI Support for HTTP/1.1

<URL:http://www.webthing.com/cgiplusplus/http1.1.html>

At the time of writing, HTTP/1.1 defines several new methods: OPTIONS, PUT, DELETE and TRACE. The Current CGI standard 1.1 predates this, and leaves the definition of a CGI interface for these methods undefined. Neither the (expired) Internet Draft at <URL:http://www.ast.cam.ac.uk/%7Edrtr/cgi-spec.html> nor the popular "de facto standard" specification at <URL:http://hoohoo.ncsa.uiuc.edu/cgi/interface.html> make any mention of the new methods, that might be of assistance to software developers.
The CGI/1.1 standard is now at http://www.golux.com/coar/cgi/. Although some of the issues have been clarified, CGI++ is unaffected, and the discussion on this page still holds.

The question then arises: should these methods be available to CGI programs, or should they always be handled by the HTTPD? My view is - emphatically - that CGI must be an option. It should be up to the Server to define whether a particular request is translated to a CGI call, with reference to the URI requested and the Server's configuration files.

I would contend that this view is strongly supported by Robinson's introductory paragraph:

The Common Gateway Interface (CGI) is a simple interface for running external programs, software or gateways under an information server in a platform-independent manner. Currently, the supported information servers are HTTP servers.

which appears to envisage (as I do) potential for a CGI-like interface to other RFC822-based protocols, such as Mail and News.

Let us consider an example of an application: website management on a remote ISP's server, using a Web browser. This is clearly a useful and popular type of application, to the extent that Netscape introduced the "file upload" facility precisely to cater for it. This should, in principle, be a straightforward CGI application using the HTTP/1.1 methods:

The HTTPD is configured to map all requests for URLs of the form "http://server.domain/sitemgr/path/to/file.name" to a "sitemgr" CGI program, with PATH_INFO set to "/path/to/file.name".
An OPTIONS request causes the CGI to check the originator's authorization, and includes PUT and DELETE in the response if and only if the agent is indeed authorised to update the site.
A PUT or DELETE request is verified by the CGI, and is either acted on or refused (or possibly rejected as unnecessary if indicated by, for example, an "If-unmodified-since" header). Further form data - such as "force overwrite if exists", "map to other path in server's filesystem", or attributes such as mime-type or expiry date, might also be supplied: handling of these would be the responsibility of the CGI author, and justifies the use of CGI rather than direct HTTP in this application.
If accepted, a PUT option returns 301 to indicate a URL where the new resource will be accessible via GET, without recourse to "sitemgr".

Additional FORM data may reasonably be passed to CGI via any of the existing mechanisms. My personal preference is to URLencode it in QUERY_STRING, in the manner of GET and HEAD.

CGI++ Support for HTTP/1.1

CGI++ incorporates provisional support for HTTP/1.1, by implementing the regime described above:

Request methods OPTIONS, PUT, DELETE and TRACE are accepted. Unknown methods are assumed to be Extension methods: CGI++-based programs should return 501 if presented with a method the application doesn't know.
Information is available via the standard mechanisms: CGI++ programs may use all CGI environment variables and permitted HTTP headers, as well as application- or browser- specific extensions.
All HTTP/1.1 General Headers, Request Headers and Entity Headers are explicitly made available, together with some extra parsing functions.
If present, QUERY_STRING is parsed as Form data.
If a document body is supplied, it is read raw and unprocessed into a char* buffer, which is at the program's disposal (along with the necessary headers, such as Content-type).

A further issue arises here: CGI/1.1 guarantees CGI a valid Content-Length whenever a document body is supplied. HTTP/1.1 does not guarantee this, and it is not defined whether a Server must synthesise one before calling CGI (this may call for a distinction along the lines of NPH vs normal CGI). The current release of CGI++ does not address this issue.