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

[Phillip J. Eby]

At 10:20 PM 10/4/2007 +1000, Graham Dumpleton wrote:
>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

You can, as long as you pass in the exception info -- because an 
exception is the only legitimate reason to change the values.



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

Actually, the PEP example skips empty strings yielded by the 
app_iter.  wsgiref.handlers, OTOH, doesn't do this, now that I've checked it.


>and quite likely that other implementations have copied from
>that and not implemented the WSGI specification as written.

Correct WSGI 1.0 implementations are unfortunately rare.  Even 
wsgiref gets it wrong.  :(


>So most likely no one probably gets it exactly right per spec,

No kidding!

>but in
>practice it probably doesn't matter anyway and isn't going to affect
>how anything works.

Yep, but another argument in favor of getting rid of as much 
statefulness from the protocol as we can.  Making the status and 
headers part of the return value entirely eliminates the question of 
when they're going to get written, and whether they can be changed.

(As a side benefit, making the return a 3-tuple makes it impossible 
to write a WSGI app using a single generator -- thereby discouraging 
people from using 'yield' like it was a CGI "print".)