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.