Re: more comments on Robinson's CGI spec.

Dave Kristol (dmk@allegra.att.com)
Tue, 21 Nov 95 16:22:01 EST


drtr1@cus.cam.ac.uk (David Robinson) wrote:
> >[DMK wrote]
> >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.
Could you elaborate, please?
>
[...]

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