Ok, I'll change the name.
> > >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.
Hmm, maybe; I'm not yet convinced. Can you think of a concrete example?
> > >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....
No and no. But you misunderstood; I wasn't suggesting not using standard I/O
streams; I was suggesting that the standard I/O streams _not_ be required
to be on top of file descriptors for a Unix socket connection to the client,
i.e. I want to allow the I/O streams to be pipes to the server process only.
> > >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.
That is intentional. It is how current servers behave; they do not requre
the Status line to come first. In practice, it is not a problem. The script
will probably send fewer headers than the client did, and the server saved
all those headers.
> In practice, there's going to be a limit. Requiring
> the CGI headers to be first solved this problem.
But it would conflict with existing practice.
>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.
Yes.
> >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.
Ok.
> 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.
Hmm, that's a good point. (I never imagined a Fortran 77 CGI script, for
example.)
David.