[Web-SIG] [extension] x-wsgiorg.flush
manlio_perillo at libero.it
Thu Oct 4 15:53:04 CEST 2007
Phillip J. Eby ha scritto:
> 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
>> > Argh. You're right. I forgot about that bit. It has been a few too
>> > many years since I worked on the spec. :)
>> 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?
Django, as an example, uses WSGI "only as a backend".
Django design is not based on WSGI, it is WSGI that is adapted for Django.
An interesting example: to add support for CGI, it seems that the
preferred method is to add a direct Django adapter for CGI, instead of
using a WSGI adatper for CGI.
>> > 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
>> > WSGI 2.0 written and into widespread use, than creating niche
>> > 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
return '200 OK', [('Content-Type', 'text/plain')], ['a', 'b']
is not allowed.
The response object can be a generic iterator, however.
> 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.
This is the reason why I don't like WSGI 2.0 :).
However I have to admit that developing a full asynchronous application
is not easy, notably when we have to interact with a database and a
It is really so hard to implement WSGI 1.0 and to write middlewares for it?
Is this really causing problems for WSGI adoption?
I think that WSGI 2.0 should simply correct some problems in WSGI 1.0,
and clarify some points, since now we have a WSGI implementation for
Apache and Nginx.
> can pause body output by yielding empty strings, but you need to have
> already decided on your headers.
And this will make asynchronous applications not really useful, IMHO...
But here I will say more once I'll implement some asynchronous
extensions for nginx mod_wsgi.
It's very unfortunate that the WSGI implementation in Twisted just uses
threads instead of doing some experimentation.
Regards Manlio Perillo
More information about the Web-SIG