[Web-SIG] [extension] x-wsgiorg.flush
manlio_perillo at libero.it
Wed Oct 3 20:24:05 CEST 2007
Phillip J. Eby ha scritto:
> At 07:03 PM 10/3/2007 +0200, Manlio Perillo wrote:
>> Phillip J. Eby ha scritto:
>> > Thinking about this made me realize that WSGI 2.0 isn't going to be
>> > to validate *anything* about a response by raising an error in the
>> > application, because everything is done after the code returns.
>> In this case, if the cache validation fails, we just have to generate
>> the body content.
>> For which cases do you want to raise an exception?
> Sorry, I thought you were talking about validating headers for *errors*
> (e.g. WSGI compliance problems), not providing special support for If-*
Ok, my message was not very clear.
> I don't think there's any point to having a WSGI extension for If-*
> header support. All the necessary data is in the environment, so it can
> trivially be implemented as a library or middleware, especially if the
> application postpones body content generation to an iterator.
> Since WSGI is intended to reduce web framework proliferation, one should
> never implement with middleware or a WSGI extension anything that can
> just be released as a library for others to use.
In general this is true, however to add support for If- headers, I do
not have to write any code, all I need is to be able to send the headers
before the body content is generated.
A wsgiorg.flush extension can be useful for some other things.
As an example, when in Nginx we send some data, an output buffer like
gzip can buffer data for efficienty, and with wsgiorg.flush a WSGI
application can force the buffer to be flushed (ok, the WSGI already
states that the WSGI gateway should not buffer the data).
Note that in Nginx, unlike Apache, an output buffer can process a
partial buffer, so, for a WSGI application like:
start_response('200 OK', [...])
the 'xxx' string is sent to the next output buffer, and, finally it is
sent to the client.
Now can happens that the socket is not ready to send further data, so
the application must be paused until the socket is ready.
When the socket is ready, the next buffer can be sent to the next outpup
buffer, and so on.
NOTE: this is not yet implemented in nginx mod_wsgi.
Regards Manlio Perillo
More information about the Web-SIG