W3C home > Mailing lists > Public > www-talk@w3.org > November to December 1995

Re: more comments on Robinson's CGI spec.

From: Dave Kristol <dmk@allegra.att.com>
Date: Tue, 21 Nov 95 16:22:01 EST
Message-Id: <9511220131.AA02935@ig1.att.att.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:18 GMT