httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject CHANGES entry on nph- CGIs
Date Tue, 30 Sep 1997 21:08:47 GMT
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]




Mime
View raw message