If you write a wsgi server that relies on the handler's close() method being
called for requests, you find out that if the browser disconnects mid-stream,
close is never called.
The attached patch should be self-explanatory. It fixes this problem.
Thanks
-Ken
diff -ur wsgiref.orig/handlers.py wsgiref/handlers.py
--- wsgiref.orig/handlers.py 2006-12-15 18:19:56.000000000 -0700
+++ wsgiref/handlers.py 2006-12-15 18:43:46.000000000 -0700
@@ -87,6 +87,7 @@
# the double-error branch here, you'll break asynchronous servers by
# prematurely closing. Async servers must return from 'run()' without
# closing if there might still be output to iterate over.
+ self.close_called = False
try:
self.setup_environ()
self.result = application(self.environ, self.start_response)
@@ -94,6 +95,10 @@
except:
try:
self.handle_error()
+ # finish_response is supposed to call close. But if finish
+ # response never really finishes...
+ if not self.close_called:
+ self.close()
except:
# If we get an error handling an error, just give up already!
self.close()
@@ -257,6 +262,7 @@
Subclasses may want to also drop the client connection.
"""
+ self.close_called = True
try:
if hasattr(self.result,'close'):
self.result.close()
Binary files wsgiref.orig/handlers.pyc and wsgiref/handlers.pyc differ
Binary files wsgiref.orig/simple_server.pyc and wsgiref/simple_server.pyc differ
_______________________________________________
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
