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

[Phillip J. Eby]

At 10:57 AM 10/4/2007 +0200, Manlio Perillo wrote:
>Phillip J. Eby ha scritto:
> > [...]
> >> There is a problem here: a WSGI gateway is not allowed to send headers
> >> until the app_iter yields a non empty string or the iterator is exausted.
> >
> > Argh.  You're right.  I forgot about that bit.  It has been a few too
> > many years since I worked on the spec.  :)
> >
>
>07-Dec-2003!
>And yet it seems that WSGI is not pervasively used.

What do you mean?  Can you name a popular Python web framework or 
library that doesn't either use or support WSGI?


> > Still, this is yet another example of why WSGI 2.0 is a big improvement
> > in simplicity.  So I still would rather see more effort put into getting
> > WSGI 2.0 written and into widespread use, than creating niche extensions
> > to 1.0.
>
>
>My implementation of mod_wsgi for nginx implements WSGI 2.0, and now I'm
>removing the limitation that the app_iter must yield only one item.

Eh?  I don't understand what you mean by "app_iter must yield only 
one item".  In WSGI 2.0 the application return signature is a 
three-item tuple, the third item of which is a WSGI 1.0 response object.


>However there is a problem with WSGI 2.0.
>
>Suppose that I execute an asynchronous HTTP request to obtain some data
>from a remote server.
>
>I can use the yet to be implemented wsgi.pause_output extension for
>this, or an extension for interfacing with nginx subrequest API.

That won't be possible in WSGI 2.0 - it's a purely synchronous 
API.  You can pause body output by yielding empty strings, but you 
need to have already decided on your headers.


>What happens if the HTTP request returns a 404 and I want to return this
>status code to the original client?
>
>This can be done in WSGI 1.0 (since I can call start_response in the
>app_iter generator) but cannot be done in WSGI 2.0.

In WSGI 1.0, that can only happen up until the point where you've 
yielded body output.  As soon as there is any body output, the 
headers are committed.  In 2.0, you will have to commit your headers 
at return time.

Note, by the way, that WSGI 2.0 isn't going to be an immediate or 
complete replacement for 1.0 -- especially since the spec isn't 
written yet!  1.0 apps and servers will likely be with us for a few years yet.