Makes sense. I've changed this to Cc: to the http-wg, and To:
www-talk. Would those replying please drop the http-wg from the Cc:
list?
> > 3) Is anyone working on such a thing now?
> Yes. I have written a fairly formal specification of CGI.
> See <URL:http://www.ast.cam.ac.uk/~drtr/cgi.html>
Nice work. I wish I'd had when I was implementing mine. It's good to
see that W3C is pointing to that as the spec as well. However, I have
a few quibbles. Naturally, I can't seem to reach hoohoo.ncsa.uiuc to
check some things on it, either. Grumble.
On to the quibbles.
1) The AUTH_TYPE section mentions HHTP. Presumably this is a typo.
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.
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. 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.
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. Better wording might be:
Some platforms support a method for providing one or more
argument strings to a script. This first argument is used in
the case of .... If there is no such argument, it should be
the empty string, and further arguments are reserved for
server-specific uses.
Sorry, I don't feel up to trying to rephrase the "ISINDEX" quote to
cover the missing cases when it's not clear what those are yet.
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.
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.
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.
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.
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.
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.
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