WSGI spec clarification regarding exceptions

A

Adam Atlas

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

Graham Dumpleton

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).
Click to expand...

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,
(e-mail address removed) 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
 
G

Graham Dumpleton

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,
(e-mail address removed) 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/
Click to expand...

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Exception handling in Python 3.x 26
Cleaning out the cobwebs in the PEP cupboard 0
Semantics of propagated exceptions 5
use of assert in Java [vs. exceptions] 22
custom exceptions don't display line numbers 1
Understanding and Using Exceptions 1
PEP 333: Python Web Server Gateway Interface v1.0 0
PyWart: PEP8: a seething cauldron of inconsistencies. 1

Members online

No members online now.
Total: 34 (members: 0, guests: 34)
Robots: 612

Forum statistics

Threads
473,769
Messages
2,569,581
Members
45,056
Latest member
GlycogenSupporthealth

Latest Threads

Top