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):
try:
return self.respond(environ, start_response)
except:
self.cleanup()
raise
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
[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
