[Web-SIG] Web Container Interface
ianb at colorstudy.com
Wed Jan 28 23:19:22 EST 2004
On Jan 28, 2004, at 9:15 PM, Jacob Smullyan wrote:
> One part of the PEP (which I may be looking at in an older version)
> that attracted my attention:
> 3. Since ``output`` and ``errors`` may not be rewound, a container is
> free to forward write operations immediately, without buffering.
> In this case, the ``flush()`` method may be a no-op. Portable
> applications, however, cannot assume that output is unbuffered
> or that ``flush()`` is a no-op. They must call ``flush()`` if
> they need to ensure that output has in fact been written.
> Luckily, the use of ``output.flush()`` is only an issue for
> applications performing "server push" operations, since closing
> ``output`` will also flush it. Applications writing logs or other
> output to ``errors``, however, may wish to perform a flush after
> each complete item is output, to minimize intermingling of data
> from multiple processes writing to the same log.
> One useful feature of SkunkWeb is that it makes it easy to have work
> performed after a response is sent, rather than before -- refreshing
> caches, rolling back database connections, etc. This is a
> considerable benefit in http, since requests are by their nature
> sporadic, and the crunch times are during request processing. The
> container interface proposed offers only one hook for a web
> application (or whatever you want to call it) to do everything it is
> going to do. Therefore, the only way to ensure that work is performed
> after the response is sent is to flush or close output before
> undertaking that work. 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. (It is debatable whether the error stream should be
> subject to this limitation; it might even be preferable for some
> containers to buffer error until after runCGI() has been completed.)
Wouldn't it be sufficient to close the stdout stream? This could be
done before runCGI returns, and would (I presume) signal that execution
had completed. Though that should be explicit. Obviously some
containers (ack, too many alternative terminologies at this point) will
not be able to finish the request until after control has been returned
from runCGI, but I don't see how that can be helped.
In general, fewer gateways would have to buffer output until after
control was returned, if headers weren't included in the output stream.
You could parse the headers at the soonest moment, and then connect
the application to the actual client in a more direct fashion after
that time. I suppose that only requires looking for \n\n (or a chunk
that ends in \n, and another that starts in \n), but it's still
annoying. Anyway, if a container sends the complete request when
stdout.close() was called, control would at least temporarily be passed
to the container, while the application would still have a chance to do
some processing after stdout.close returns, and before runCGI returns.
Maybe those semantics -- or even a lack of required semantics -- should
be included in the PEP.
Actually ensuring that flush sends data to the client is hard, as there
can be many levels of buffering. But I don't see why it would be
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org
More information about the Web-SIG