httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sameer <sam...@c2.net>
Subject Re: CHANGES entry on nph- CGIs
Date Tue, 30 Sep 1997 21:08:41 GMT
	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.

> 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

Mime
View raw message