> >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 I see what your description is trying to say, but I think it
needs to be improved. You're saying (yes?) that PATH_TRANSLATED
corresponds to the file (resource?) you would be referring to if the
original request had been
protocol://SERVER_NAME:SERVER_PORT enc-path
where "enc-path" is the URL-encoded PATH_INFO. (Isn't "protocol"
always "http"?) Somehow I didn't get that the first few times I read this.
I think my problem is that here (and in the PATH_INFO section) you
leave unspecified how it is that PATH_INFO is arrived at, yet under
"Defining a script URI" you make it clear it's the part after
enc-script, which is what I would have expected. I would guess you're
drawing a distinction between CGI's that are called as a result of URL
processing and CGI's that are called by some other mechanism, in which
case PATH_INFO would be derived some other way.
[...]
> >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?
See above. I think I'm finally catching on to your point.
>
[...]
> >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.
Ah!
>
> >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.
I guess this is another case where either what happens should be spelled
out (for all systems), or it should be made "implementation-defined".
>
[...]
Dave Kristol