On Tue, 30 Sep 1997, Dean Gaudet wrote:
> > the output before sending. The programmer can still use "nph-"
> > CGIs, which provide a direct socket to the client without
> > Apache getting involved, but they are no longer necessary for
> > many applications. "nph-" CGIs are not fully compatible with
>
> They're not at all compatible with HTTP/1.1 unless they implement
> chunking.
They are completely compatible with HTTP/1.1 without implementing chunking
iff clients aren't sending data to them with a PUT, etc. Saying they are
not compatible implies that they will fall over horribly. In reality,
they will only do so under certain conditions. Nothing is preventing a
nph CGI from sending a non-chunked HTTP/1.1 response or a HTTP/1.0
response to a 1.1 request. People just scare easily.
On Tue, 30 Sep 1997, sameer wrote:
> Actually, now nph CGI *is* compatible. nph stands for
> "non-parsed headers" -- it doesn't stand for "direct socket
> connection" -- Before the nph- meant you had a direct socket
> connection, which wasn't really the true meaning of nph. Now nph means
> that the headers are passed direct to the client, without being
> parsed.. I.e. non-parsed.
Erk. That is bad. That breaks something. Well, it could just be the
current implementation. Unbuffered CGIs aren't working well for me. Not
well enough to get rid of nph == direct socket. More when I have looked
at what is happening...
>
> > I'm still not sure I like this:
> >
> > *) "nph-" CGIs were not compatible with HTTP/1.1 or SSL support because
> > they were passed a socket that connected directly to the client.
> > As such they would have to implement the transport level details
> > such as encryption or chunking in order to work properly.
> > This isn't part of the CGI spec so CGIs generally don't do this.
> > The most common use of nph- CGIs is when the programmer wants an
> > unbuffered connection to the client; regular CGIs have always been
> > fully buffered. Apache now provides an unbuffered connection to
> > all CGIs. Given that most CGIs are written in a language that by
> > default does buffering (i.e. perl) this shouldn't have a detrimental
> > effect on performance. The programmer can still use nph- CGIs,
> > and they're still responsible for sending valid HTTP/1.1 responses.
> > [Dean Gaudet, Sameer Parekh, Roy Fielding]
> >
> > It says nph- CGIs were not compatible. They still are not compatible, so
> > were incorrectly implies it has changed.
> >
> > The description of what the feature is should be at the start, not hidden
> > in the end.
> >
> > How about changing it to:
> >
> > *) Apache now provides an effectively unbuffered connection for
> > CGI scripts. This means that data will be sent to the client
> > almost as soon a the CGI outputs it; previous, Apache buffered
> > the output before sending. The programmer can still use "nph-"
> > CGIs, which provide a direct socket to the client without
> > Apache getting involved, but they are no longer necessary for
> > many applications. "nph-" CGIs are not fully compatible with
> > HTTP/1.1 or SSL support because they are passed a socket that
> > is connected directly to the client. As such they would have to
> > implement the transport level details such as encryption or
> > chunking in order to work properly in certain situations.
> > This isn't part of the CGI spec so CGIs generally don't do
> > this; more importantly, they should not need to know such
> > transport level details. Given that most CGIs are written in
> > a language that by default does buffering (e.g. perl) this
> > shouldn't have a detrimental effect on performance. [Dean
> > Gaudet, Sameer Parekh, Roy Fielding]
> >
> >
> >
>
>
> --
> Sameer Parekh Voice: 510-986-8770
> President FAX: 510-986-8777
> C2Net
> http://www.c2.net/ sameer@c2.net
>
|