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

more comments on Robinson's CGI spec.

From: Dave Kristol <dmk@allegra.att.com>
Date: Thu, 16 Nov 95 08:39:44 EST
Message-Id: <9511161340.AA02938@www10.w3.org>
To: www-talk@w3.org
[I posted this to http-wg yesterday.  I should have posted it here.
Apologies to those who get it twice.]

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.  With NCSA's server, the original request is
    	http://$SERVER_NAME$SERVER_PORT$SCRIPT_NAME$PATH_INFO{?$QUERY_STRING}

    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!

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 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.  (A client must specify some character to take the place
    of URL in the request line.  That character would logically be a
    part of PATH_INFO as currently described.)

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.

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.

Data output from the CGI script: Status
    I believe Status: can have an optional comment:
    	Status = "Status" ":" 3digit *<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?

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 "//".

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.

Dave Kristol
Received on Thursday, 16 November 1995 08:40:09 GMT

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