Re: more comments on Robinson's CGI spec.

David Robinson (drtr1@cus.cam.ac.uk)
Tue, 21 Nov 95 18:07 GMT


>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.

I agree. If you want relative links, then it is useful. However...
>
>With NCSA's server, the original request is
> http://$SERVER_NAME$SERVER_PORT$SCRIPT_NAME$PATH_INFO{?$QUERY_STRING}

Unfortunately not in a few obscure cases.

> 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!

This sounds good. Wilco.

>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 don't understand this. What convention do you mean? Are you suggesting
that the name is poorly chosen, that it should be enc-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....

I think the latter is what I mean by enc-path{-info}.

>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.

I don't see any conflict. I must have explained it badly, but where?

>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.

Yes, thanks.

>Data output from the CGI script: Status
> I believe Status: can have an optional comment:
> Status = "Status" ":" 3digit *<not NL> NL

Hmm. I'd forgotton about that. I note that in HTTP, the comment is
_not_ optional (although it can be NULL). Also, the NCSA docs do not
make it optional.
I'll change this to
Status = "Status" ":" 3digit SP *<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?
I'll expand this; usually the NL convention will differ, but the character
set used may be different.

>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 "//".
Maybe they should, but some servers don't. NCSA folded "..", but not ".".
I now don't think the server should touch "//", because the script may
have a use for it; one example would be passing URLs in the PATH_INFO.

>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.

Good point; I'll add this.

David Robinson.