At 12:30 PM 10/4/2007 +1000, Graham Dumpleton wrote: >On 04/10/2007, Phillip J. Eby <[EMAIL PROTECTED]> 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. _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com