httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: CHANGES entry on nph- CGIs
Date Tue, 30 Sep 1997 21:13:26 GMT


On Tue, 30 Sep 1997, Marc Slemko wrote:

> 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

They're not at all compatible with HTTP/1.1 unless they implement
chunking. 

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

Otherwise, sure.  And +1 to any other reordering of the CHANGES that makes
more sense... reverse chronological isn't the most useful on large
releases.  There's probably a few we missed in the new_features_1_3
document.  I tried to get all the stuff I did. 

Oh btw, I found under linux that the kernel buffers 4k worth of data
before the task loses its time slice -- so even if the app isn't buffering
the kernel might do some.  This is OK because if the CGI were to
deliberately lose its time slice (say, by blocking on some other i/o) then
httpd would pick up and flush out whatever was there. 

Dean


Mime
View raw message