[Web-SIG] [extension] x-wsgiorg.flush
Manlio Perillo
manlio_perillo at libero.it
Thu Oct 4 10:57:08 CEST 2007
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.
> 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.
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.
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.
A possibile solution for WSGI 2.0 is to add a wsgi.response_error exception:
raise environ['wsgi.response_error'](status='404 Not Found)
However there is still the problem with the headers.
Regards Manlio Perillo
More information about the Web-SIG
mailing list