[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
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