WSGI spec clarification regarding exceptions

Wed May 9 22:07:21 EDT 2007

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,
 you 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/

Graham