[Web-SIG] [extension] x-wsgiorg.flush

[Manlio Perillo]

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 
>> able
>> > 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-* 
> headers.
> 

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', [...])

    yield 'xxx'
    yield 'yyy'
    yield 'zzz'


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