Re: CGI???

David Robinson (drtr1@cus.cam.ac.uk)
Wed, 15 Nov 95 15:43 GMT


>From: mwm@contessa.phone.net (Mike Meyer)
>...
>On to the quibbles.
>...
>2) I think it should be changed to allow multiple protocols in both
>GATEWAY_INTERFACE and SERVER_PROTOCOL. Follow the HTTP draft for the
>User-Agent: field. This is a real change from current behavior, but I
>believe such an implementation would meet the NCSA spec. As an example:
>
> GATEWAY_INTERFACE = CGI/1.1 NCSA/1.4
>
>indicates that this server supports the extra variables from NCSA 1.4,
>etc. SERVER_PROTOCOL already has an "extension-version" option, this
>just generalizes that.

I don't agree. This would not be compatible with existing applications, which
may do a string comparison for "CGI/1.1".

>3) The CGI command line description has some serious errors. You don't
>get an argument only for ISINDEX query; not even according to this
>spec.

Yes you do; the spec _defines_ an ISINDEX query.

>An imagemap query meets the criteria as stated, and the NCSA 1.3
>implementation certainly provided an argument (and the supplied
>imagemap program expected one). I also don't see any reason to
>restrict the argument to a GET request, unless you want to actively
>discourage people from putting data in command line arguments.

It should allow HEAD, maybe; but not POST.

>4) I think the reference to the "array of strings" in the CGI command
>line section is misleading. Currently, only one is used, and it's
>passed to the script as if it were the first argument and the script
>had been invoked from the command line....

That is not the behaviour as I understand it;
http://host/cgi-bin/script?foo+bar
runs
script foo bar
not
script "foo bar"

>5) As to telling the difference between a missing body and a
>zero-length one, the presence (or absense) of Content-Type: can do the
>trick. If it's not there, there's no body. If it is there, the body
>has a length of zero.

Correct; thanks.

>6) Under requirements for servers, you say:
>
> Servers should reject with error 404 any requests that would
> result in an encoded "/" being decoded into PATH_INFO or
> SCRIPT_NAME.
>
> Note: this should be made a requirement.
>
>Why? Remember that the justification can't include the semantics of
>the underlying file system.

It's nothing to do with the file system semantics; the semantics of a URL
use unencoded / as a path component separator. If you decode encodeded '/',
then you would incorrectly change the semantics of the URL.

>7) The "Data input", and "Data output" requirements should be
>appreciably tightened, to indicate that servers should tie the default
>input and output streams to the incoming object and output to the
>client. Since it may not be possible, we can't require it. But that's
>the desired behavior if it's possible.

I don't think it is desirable, except in the case of nph scripts.
Otherwise, the server is restricted to HTTP/1.0-style single requests
per connection. If the server is allowed to buffer script input and output,
then it can support multiple requests per connection even for CGI scripts.

>8) You've made a quiet change to the behavior of parsed headers -
>requiring that the CGI headers appear before the HTTP headers. A good
>idea, but this should be noted.
Not intentional; I'll correct this. Thanks.

>9) It appears you've made another quiet change to the location:
>header. I recall that NCSA required URL's that resolved to the server
>to be handled on the server, whereas you've chaged it to be only URL's
>without a scheme. I heartily approve, but think this should be noted
>as well.
I think your recollection is at fault.

>10) If the recommended changes to command line and I/O streams
>sections are made, then those parts of the system-specific information
>for unix are redundant, as it complies with the recommended behavior.
Yes, it can be made neater there.

>11) Amiga system-specific standards:
>
>Not a quibble, an addition to the system-specific information at the end:
>
>AmigaDOS
>
>Environment variables
>
> These are accessed by the dos.library routine GetVar. The flags
> argument should be 0. Case is ignored, but upper case is
> recommend for compatability with case-sensitive systems.
>
>The command line and I/O streams follow the "should" recommendations,
>and aren't required in this one.
>
> Thanx,
> <mike

Included.

I've updated the spec as a result of your comments; please have
another look.

David.