[Web-SIG] Write buffering (was Re: WSGI uses)

[Phillip J. Eby]

At 11:43 AM 8/20/04 -0500, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>True enough.  I've not seen a problem with CGI myself, but I believe some 
>>CGI-based protocols (not FastCGI, but some clones of it) buffer entire 
>>requests no matter what you do.  WSGI servers or gateways that can't do 
>>streaming should document that fact.  Or perhaps there should be two 
>>compliance levels: WSGI Basic and WSGI Streaming.
>
>It could just be something like a 'wsgi.streaming' key in the environment, 
>no?  Gateways should be encouraged to set that to false until they've 
>confirmed that streaming really works consistently.

I think I've convinced myself that servers or gateways must *always* 
attempt to stream data passed to write() or yielded by the iterator.  The 
only time this can cause any problems is if the application sends lots of 
small strings, and the I/O is single-threaded and unbuffered.  As a 
practical matter, TCP/IP stacks usually have at least a K or two of 
outbound buffering for a connection, don't they?  So until that fills up, 
the application will continue to execute normally.  It's not as good as 
something better, but it'll do.

So, I'm updating the spec and recommending that applications do buffering 
of their own for "moderately sized" responses that are neither too large 
for buffering nor too small to worry about it.  I know that Zope, for 
example, normally generates its body output as one big block anyway, and I 
think the common pattern for e.g. Python page templating systems is to 
produce their output as a single string, rather than in pieces.  So, it 
would seem in common cases that there will only be one write() call 
anyway.  (Especially since buffered dynamic output gives an application an 
error-handling advantage: it can send an error page rather than dumping 
error garbage into the middle of a partially-completed response.)