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

Graham Dumpleton graham.dumpleton at gmail.com
Fri Oct 5 01:03:40 CEST 2007


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

Okay, forgot about that case. Luckily my code appears in the main to
do the correct thing, although I'll need to check a few corner cases
as looks like the traceback I log when start_response() called with
exception after data written is a bit wrong as doesn't identify the
original exception type correctly. This may just be an issue with how
I log exception details from C API. The yielding of empty strings
prior to calling start_response() with exception details also gives me
strife as appear not to return any response to client at all, ie., no
headers or body. So, little bit of tweaking to do.

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

True again. I was only looking at the internals of write() and so
missed that iteration would eliminate empty strings.

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

Too early for me to be thinking straight and work it out for myself,
but does this all help in making it simpler or more obvious what the
cleanup requirements are for a generator. Ie., correct use of
try/except/finally around yield and purpose of close() function. I've
seen a number of people not get this correct in stuff and tried to
correct them. Hopefully I have captured what should be done correctly
in my document:

  http://code.google.com/p/modwsgi/wiki/RegisteringCleanupCode

If I haven't please let me know. :-)

Graham


More information about the Web-SIG mailing list