Fair enough. Maybe for CGI/1.2. But I want you to hold that thought.
> >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.
In which case I think the word "ISINDEX" is poorly chosen. The only
other place I've seen it is as an HTML tag, which tag causes user
agents to let users generate such queries. However, ISINDEX queries
can also be generated by simple links (i.e. - the author included the
query in the URL) and image maps.
Possibly calling it an "indexed" query would be less confusing.
> >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.
> >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.
Hmm - possibly this should be broadened a little bit, allowing the
server to send a 404 error if the PATH_INFO or SCRIPT_NAME fields look
to be a security problem as far as the server is concerned. This would
make such behavior implementation dependent. I can see wanting both
the server to protect you from this (and deal with ".." & etc. things,
as someone else suggested) and wanting the server to not fool with
things.
> >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.
Now, pull that thought I asked you to hold. Are there any existing CGI
implementations that don't use the standard I/O streams? Are there any
existing CGI applications that won't break on a server that chooses
not to implement the two streams in that way? This also breaks
existing applications.
Yes, things currently being experimented with might well want (do
want? I don't know) another mechanism. I think that should be pushed
into CGI/1.2 as well.
> >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.
There's a problem with this version. The server can't send any data
until the Status: header has been seen. This means the server has to
save the potentially unlimited set of HTTP headers until the status
header is seen. In practice, there's going to be a limit. Requiring
the CGI headers to be first solved this problem. A comment that
nscripts should send the status header first might be appropriate, or
a warning about abusing the ability to not send it first.
> >11) Amiga system-specific standards:
> Included.
Please delete the comment about main(), argc & argv. AmigaDOS doesn't
attach magic to the name main(), and doesn't provide an array of
strings as arguments. Actually, the magic of the main() procedure is C
specific even on Unix. Other languages don't necessarily have a
main(), and may not get the command line arguments as arguments to the
initial procedure.
Thanx,
<mike