[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.  :)

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