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.