<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>RE: [Web-SIG] Another WSGI gotcha to be aware of</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Phillip J. Eby wrote:<BR>
> At 11:45 PM 8/24/2007 -0700, Robert Brewer wrote:<BR>
> >However, and here's the rub, if nextapp() raises an<BR>
> >exception, **self.response is never bound**, and<BR>
> >therefore we have no handle to the object we need<BR>
> >to close. Note that this is not a middleware-only<BR>
> >problem; servers can run into this too.<BR>
> ><BR>
> >The spec says, "In general, applications *should* try to<BR>
> >trap their own, internal errors"; we might want to make<BR>
> >that a MUST in future versions. Alternately, we could<BR>
> >require that every application provide its resource-<BR>
> >releasing endpoint via some means other than a successful<BR>
> >response. I'm sure you all can come up with other solutions.<BR>
><BR>
> I don't see a problem here to solve. If the application<BR>
> didn't return a response, the middleware naturally isn't<BR>
> obligated to call close() on it.<BR>
<BR>
Sorry; I didn't mean to imply that WSGI server interfaces<BR>
need to be fixed in an way.<BR>
<BR>
As the author of a WSGI application interface, it means<BR>
you have to call your own resource cleanup code if an<BR>
exception is raised while you're being called (as opposed<BR>
to having the response iterated over):<BR>
<BR>
def __call__(self, environ, start_response):<BR>
try:<BR>
return self.respond(environ, start_response)<BR>
except:<BR>
self.cleanup()<BR>
raise<BR>
<BR>
Some applications don't do this, so my primary message<BR>
is to authors of WSGI application interfaces (including<BR>
all middleware) to check your code and make sure you do<BR>
it, rather than just let errors propagate out.<BR>
<BR>
Some application authors may have chosen to not do this<BR>
because the spec says, "should try", not "must". So I'm<BR>
thinking of ways to improve that situation, all the way<BR>
from "do nothing" to "clarify the language in the spec"<BR>
to different conversation models in future specs.<BR>
<BR>
<BR>
Robert Brewer<BR>
fumanchu@aminus.org</FONT>
</P>
</BODY>
</HTML>