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

Re: more comments on Robinson's CGI spec.

From: David Robinson <drtr1@cus.cam.ac.uk>
Date: Tue, 21 Nov 95 18:07 GMT
Message-Id: <m0tHx6g-000DJKC@ursa.cus.cam.ac.uk>
To: dmk@allegra.att.com
Cc: drtr1@cus.cam.ac.uk, www-talk@w3.org
>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.
>    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

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.

>    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.
Received on Tuesday, 21 November 1995 13:09:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:58 UTC