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

Phillip J. Eby pje at telecommunity.com
Thu Oct 4 13:47:15 CEST 2007


At 12:30 PM 10/4/2007 +1000, Graham Dumpleton wrote:
>On 04/10/2007, Phillip J. Eby <pje at telecommunity.com> wrote:
> > At 09:52 PM 10/3/2007 +0200, Manlio Perillo wrote:
> > >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.  :)
>
>The actual wording of the PEP does though suggest that if one calls
>write() returned from start_response() that one would flush headers.
>Ie., the requirement for a non-empty string is really only mentioned
>in reference to value returned from iterable and not in relation to
>empty data string passed to write().
>
>I am not sure I understand the importance of being strict and not
>flushing headers until the first non-empty content data block. Was
>there a specific reasoning or use case behind saying that?

The idea was to allow an application to change its mind about the 
headers until it had committed to writing data.  That is, to allow 
the application to do error handling for as long as possible before 
the server has to do it.

For WSGI 2.0, I'm no longer concerned about it - in the common case, 
the body will be a list or tuple containing a single string, so it 
can't possibly raise an error.  For anything more complex, well, you 
were going to have to handle error conditions once you yielded some 
body output anyway.

Now that you're mentioning it, the "non-empty yield" requirement 
seems pretty bogus, since it's not really possible for the app to 
tell whether headers have been sent anyway; start_response() handles 
that transparently.

Only problem is that the PEP examples and wsgiref aren't written to 
support doing it that way, so I don't think we can reasonably change 
it in WSGI 1.0, and in 2.0 it won't even matter.



More information about the Web-SIG mailing list