- From: Dave Kristol <dmk@allegra.att.com>
- Date: Tue, 21 Nov 95 16:22:01 EST
- To: drtr1@cus.cam.ac.uk
- Cc: www-talk@w3.org
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
Received on Tuesday, 21 November 1995 20:33:38 UTC