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
nor the popular "de facto standard" specification at
make any mention of the new methods, that might be of assistance to
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:
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.
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.