[Web-SIG] Another WSGI gotcha to be aware of

Robert Brewer fumanchu at aminus.org
Sat Aug 25 23:09:41 CEST 2007

Phillip J. Eby wrote:
> At 11:45 PM 8/24/2007 -0700, Robert Brewer wrote:
> >However, and here's the rub, if nextapp() raises an
> >exception, **self.response is never bound**, and
> >therefore we have no handle to the object we need
> >to close. Note that this is not a middleware-only
> >problem; servers can run into this too.
> >
> >The spec says, "In general, applications *should* try to
> >trap their own, internal errors"; we might want to make
> >that a MUST in future versions. Alternately, we could
> >require that every application provide its resource-
> >releasing endpoint via some means other than a successful
> >response. I'm sure you all can come up with other solutions.
> I don't see a problem here to solve.  If the application
> didn't return a response, the middleware naturally isn't
> obligated to call close() on it.

Sorry; I didn't mean to imply that WSGI server interfaces
need to be fixed in an way.

As the author of a WSGI application interface, it means
you have to call your own resource cleanup code if an
exception is raised while you're being called (as opposed
to having the response iterated over):

def __call__(self, environ, start_response):
        return self.respond(environ, start_response)

Some applications don't do this, so my primary message
is to authors of WSGI application interfaces (including
all middleware) to check your code and make sure you do
it, rather than just let errors propagate out.

Some application authors may have chosen to not do this
because the spec says, "should try", not "must". So I'm
thinking of ways to improve that situation, all the way
from "do nothing" to "clarify the language in the spec"
to different conversation models in future specs.

Robert Brewer
fumanchu at aminus.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/web-sig/attachments/20070825/930a92c1/attachment.htm 

More information about the Web-SIG mailing list