[Web-SIG] Web Container Interface

[Phillip J. Eby]

At 10:15 PM 1/28/04 -0500, Jacob Smullyan wrote:
>I'd be happier, therefore, if the
>specification mandated more explicitly that the container must
>actually respect the semantics of flush() -- that flush() may be a
>no-op if output is unbuffered, but it may not be a no-op if it is not.
>This means that output, for instance, could not be a StringIO object
>the contents of which the container blits back to the client after
>runCGI() returns.

This does mean that gateways that perform header parsing (i.e. gateways 
built into webservers) will need a StringIO subclass.  But that doesn't 
seem like too terrible of a burden.

I think we need to specify that flush()ed output is not guaranteed to be 
sent to the client unless the service has sent all of its headers 
already.  Then, header-parsing gateways can force output to be buffered 
until they have seen the headers.