Re: CGI???

Dave Kristol (dmk@allegra.att.com)
Thu, 16 Nov 95 08:58:14 EST

mwm@contessa.phone.net (Mike Meyer) wrote:
[...]
> > >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.

Tying the input/output to standard input/output (to use Unix terminology)
does not really constrain implementations in the face of multiple requests
per connection. (That depends on your definition of that expression. I
mean multiple consecutive requests, a la Keep-alive.) My implementation
of Keep-alive does the following with a CGI: if the protocol is HTTP/1.1
[sic], I assume the client understands Transfer-Encoding: chunked. The
server reads the CGI's output and chunks it. Chunking allows the server
to tell the client where the end of data is (instead of closing the
connection to do so).

What's nice about this is that the CGI does not require any special
coding to support Keep-alive. (Obviously NPH CGI's are a different
matter.)

>
> > >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.

I don't think this is important. As a practical matter, CGI's don't
send many headers, certainly fewer than in a request, which the server
must also buffer. I think it's easier to find the blank line that
marks the end of headers than to check each header until you find one
that "doesn't belong" (or, by the way, a blank line) to decide you've
finished with CGI headers. (At least it's easier in my implementation.
:-)

BTW, I think the term "CGI headers" is a bit odd, given that Location
and Content-Type are both HTTP headers, as well. Yeah, okay, you have
to call them SOMETHING. How about the more cumbersome "CGI-significant
headers"?

[...]

Dave Kristol