[Web-SIG] Container buffering of output.
py-web-sig at xhaus.com
Mon Aug 30 22:25:00 CEST 2004
>> In .. J2EE .. the container will do it's own buffering completely
>> outside your control, and send the pieces with chunked-transfer
>> encoding if necessary. So even if I put a flush on the output channel
>> in my framework, I'm only flushing it to the container's buffer: it's
>> still not guaranteed to send output back down the return socket to the
[Phillip J. Eby]
> That is potentially a problem, since the point is to guarantee that when
> 'write()' returns to the application, the output isn't going to just sit
> in the buffer while the application moves ahead with other things: it
> should be going to the client.
Hmmm, I don't see how it would be a problem. Although I suppose that
depends on what you mean by "the output isn't going to just sit in the
buffer": which buffer?
As you say, when the write() returns, the application's output has been
sent as far as I can send it. My entire thread of execution for a
request may have ended, and the output may still be sitting in some
container's (i.e. Apache, Tomcat) buffer, i.e. not sent to the client:
there's nothing I can do about that. I can call flush on my
OutputStream, but I can't guarantee that the container will respect that
by actually flushing to the client, for whatever reasons it may have.
This already happens with plain CGI. That's the way that containers like
Apache and Tomcat deal with most dynamic content: buffer CGI/etc output
until the buffer is full, then send a chunk to the client.
The behaviour of the container will probably be different if a
Content-Length header is set: it might pass the output straight through,
or it might still buffer it. That's container-specific.
This is all an inevitable consequence of running inside a container of
However, if the container were written in python, e.g. SimpleHttpServer,
Medusa or Twisted, they could meet the guarantee "sent down the socket
to the client before the write() returns", because they hold the socket
connected to the client. He who holds the socket calls the shots.
I don't see any of this presenting a problem for WSGI.
More information about the Web-SIG