fielding 97/09/30 14:48:40
Modified: src CHANGES Log: Improve the note about new unbuffered CGI Revision Changes Path 1.453 +16 -12 apachen/src/CHANGES Index: CHANGES =================================================================== RCS file: /export/home/cvs/apachen/src/CHANGES,v retrieving revision 1.452 retrieving revision 1.453 diff -u -r1.452 -r1.453 --- CHANGES 1997/09/30 21:02:10 1.452 +++ CHANGES 1997/09/30 21:48:37 1.453 @@ -447,18 +447,22 @@ setting. The define MAX_SPAWN_RATE can be used to raise/lower the maximum. [Dean Gaudet] - *) "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. + *) Apache now provides an effectively unbuffered connection for + CGI scripts. This means that data will be sent to the client + as soon as the CGI pauses or stops output; previously, Apache would + buffer the output up to a fixed buffer size before sending, which + could result in the user viewing an empty page until the CGI finished + or output a complete buffer. It is no longer necessary to use an + "nph-" CGI to get unbuffered output. 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. + + "nph-" CGIs, which formerly provided a direct socket to the client + without any server post-processing, were not fully compatible with + HTTP/1.1 or SSL support. As such they would have had to implement + the transport details, such as encryption or chunking, in order + to work properly in certain situations. Now, the only difference + between nph and non-nph scripts is "non-parsed headers". [Dean Gaudet, Sameer Parekh, Roy Fielding] *) If a BUFF is switched from buffered to unbuffered reading the first