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

[Graham Dumpleton]

On 04/10/2007, Phillip J. Eby <pje at telecommunity.com> wrote:
> 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.

But once you have called start_response() you cant call it a second
time to change the values so how could the application change its
mind? If you are delaying calling start_response() in the first place
it is a moot point as you cant be writing data until you do so.

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

Huh, change what in WSGI 1.0. As you seem to note the CGI example in
the PEP does flush headers even if first data block was an empty
string and quite likely that other implementations have copied from
that and not implemented the WSGI specification as written.

As to Apache mod_wsgi, if using Apache 1.3 it would flush headers if
first data block output was empty where as in Apache 2.X it will only
flush when first non empty data block is yielded, but also wouldn't
flush if write() was being called. That in Apache 2.X it doesn't flush
headers until first non empty data block is output wasn't by design,
that is just how Apache works under the covers.

So most likely no one probably gets it exactly right per spec, but in
practice it probably doesn't matter anyway and isn't going to affect
how anything works.

Graham