[Web-SIG] Web Container Interface

[Ian Bicking]

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 
necessary.

--
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org