Hi all,
I just found another corner case in the WSGI spec
that I thought I'd share so you all can check your
WSGI components for similar problems. Basically,
it comes down to error handling. Here's a simple
example:
class Middleware(object):
def __init__(self, nextapp, environ, start_response):
try:
self.response = nextapp(environ, start_response)
self.iter_response = iter(self.response)
return
except SomeException:
self.close()
def close(self):
if hasattr(self.response, "close"):
self.response.close()
def __iter__(self):
return self
def next(self):
try:
return self.iter_response.next()
except AnotherException:
self.close()
raise StopIteration
As you know, all WSGI middleware (that doesn't just pass
through the response from "nextapp") must itself possess
a "close" method so that the response from "nextapp" can
have *its* close method called. In this example, that
would be "self.response.close".
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.
Robert Brewer
[EMAIL PROTECTED]
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
