Sure. I typically use PATH_INFO to locate a file on the server. If the
program is running on a system that allows "/" in file names, why
shouldn't I be allowed to use a file that has a "/" in the name? Or is
that to vague?
> > > >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.
Ah, that I agree with - it's not clear that all systems can support
the socket/stream duality that unix does. I still think the "Unless
otherwise specified, this will" should be replaced by "This should",
but that's a minor point.
> > > >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.
Why do people keep refering to this? Is there something I missed in
the spec that requires the CGI header handling & HTTP header handling
to be the same code? As far as I can tell, there's no requirement that
they be part of the same binary. Since I implemented CGI via the
external module API, they aren't.
> > 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.
But doing it the way you do it now *also* conflicts with existing
practice. That's why I recommended that it say "Should come first".
That makes the script work on more implementation. You might also want
to say that the CGI implementation "should be prepared to handle an
arbitrary number of HTTP headers before the status" for the same
reason.
> > >11) Amiga system-specific standards:
Maybe I should stop on this until things settle down more? Anyway, the
current directory is the script directory for existing amiga servers.
Thanx,
<mike