WSGI spec clarification regarding exceptions

Wed May 9 22:51:36 EDT 2007

On May 10, 12:07 pm, Graham Dumpleton <Graham.Dumple... at gmail.com>
wrote:
> On May 10, 8:26 am, Adam Atlas <a... at atlas.st> wrote:
>
> > I'm trying to figure out if there's any defined behaviour in PEP 333
> > for instances where an application returns an iterable as usual
> > without error, but that iterable's next() method eventually raises an
> > exception. Since any data theretofore returned by the iterable must be
> > assumed to have already been written to the client, thus making it
> > impossible to replace the response with a 500 error or somesuch, does
> > the gateway just absorb the exception and cut off the response there?
> > It seems like that's pretty much all it could do, but I'm wondering if
> > that's explicitly specified anywhere (I couldn't find anything about
> > that in the PEP).
>
> Because the WSGI specification requires that a WSGI adapter for a web
> server always explicitly perform a flush after each string yielded
> from the iterator then simply cutting off the response at that point
> is all one can do as the first time a flush is done any response
> status and headers will also have to be written out.
>
> Now depending on the web server being used, all the client may see is
> the truncated page, or it might also see some form of error page
> appended to it by the underlying web server. For example, in Apache,
> if the WSGI adapter returns HTTP_INTERNAL_SERVER_ERROR back to the
> server, the server disregards whether anything has already been sent
> and tries to generate a 500 error page. Since the response status and
> headers have already been flushed though, the original status is
> received by the client, but the Apache error page content is still
> sent. Thus you might get output looking like:
>
> Hello World!
> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> <html><head>
> <title>200 OK</title>
> </head><body>
> <h1>OK</h1>
> <p>The server encountered an internal error or
> misconfiguration and was unable to complete
> your request.</p>
> <p>Please contact the server administrator,
>  y... at example.com and inform them of the time the error occurred,
> and anything you might have done that may have
> caused the error.</p>
> <p>More information about this error may be available
> in the server error log.</p>
> <hr>
> <address>Apache/2.2.2 (Unix) mod_wsgi/1.0-TRUNK Python/2.3.5 Server at
> localhost Port 8002</address>
> </body></html>
>
> It is actually hard to know what to do here. There are ways one could
> stop the appending of the error page content, but is returning just
> the truncated page any better. At least the error page content in
> there highlights an issue even if status wasn't 500, but then not
> being 500, the page content could get cached.
>
> This is where one wanders whether the WSGI way of always flushing is a
> good idea. It may be better to always use buffering unless one
> specifically knows that one wants to do streaming of data where size
> could be large or take some time to produce.
>
> Anyway, for WSGI matters, you are probably better off bringing them up
> on the Python WEB-SIG list.
>
>  http://www.python.org/community/sigs/current/web-sig/

BTW, forgot to mention that one can always create a WSGI middleware
component that does buffering and which only sends the complete
response. If an error occurs while accumulating the response, then you
can return a 500 status and error page of your own making.

Graham