Here are some more comments on David Robinson's (Oct 16 and Nov 15,
1995) CGI 1.1 specification, http://www.ast.cam.ac.uk/~drtr/cgi.html.
PATH_INFO
I think it's important for the CGI to be able to reconstruct the
original request URI. With NCSA's server, the original request is
http://$SERVER_NAME$SERVER_PORT$SCRIPT_NAME$PATH_INFO{?$QUERY_STRING}
I would prefer how PATH_INFO is set to be spelled out, not be left
so vague as to be useless for a specification. However, let me
suggest we take a page from the ANSI C standard and create
"implementation-defined" behavior. An implementation would be
required to document what its PATH_INFO (and other environment
variable) behavior is. More clearly than is now the case!
PATH_TRANSLATED
I think the description is wrong. enc-path conventionally encodes
both the name of the script and PATH_INFO, not just PATH_INFO. I
agree that PATH_TRANSLATED is a translation of the PATH_INFO.
I think "enc-path" could never be null as shown in the example,
although it can be null after the script name is stripped from
enc-path. (A client must specify some character to take the place
of URL in the request line. That character would logically be a
part of PATH_INFO as currently described.)
Defining a script URI
The information here, particularly script-uri, appears to conflict
with the information about PATH_INFO and PATH_TRANSLATED. Here we
see enc-script called out explicitly, which is what I would expect.
Data output from the CGI script: Content-Type
To answer the questions in the Note: Content-Type should be mandatory
only when there's a message body. That gets said under Parsed Header
Output.
Data output from the CGI script: Status
I believe Status: can have an optional comment:
Status = "Status" ":" 3digit *<not NL> NL
Data output from the CGI script: HTTP headers
I don't understand what this section is trying to say. For which
HTTP headers does the CGI header syntax differ?
Recommendations for scripts
Why shouldn't the CGI script expect the server to fold PATH_INFO
(PATH_TRANSLATED) information that contains "." or ".." the same
way that the server handles them in a URL? In that case, the CGI
would never actually see such stuff. Likewise for "//".
System-specific standards
I would like to see another "implementation-defined" item: for
Unix systems (at least) what is "." when the script runs? NCSA
httpd, for example, sets "." to the directory of the script.
Dave Kristol