Roundup Robot added the comment:
New changeset d5af1b235dab by Antoine Pitrou in branch '2.7':
Issue #16220: wsgiref now always calls close() on an iterable response.
http://hg.python.org/cpython/rev/d5af1b235dab
--
nosy: +python-dev
___
Python
Roundup Robot added the comment:
New changeset eef470032457 by Antoine Pitrou in branch '3.2':
Issue #16220: wsgiref now always calls close() on an iterable response.
http://hg.python.org/cpython/rev/eef470032457
New changeset 2530acc092d8 by Antoine Pitrou in branch '3.3':
Issue #16220:
Antoine Pitrou added the comment:
Your patch is now committed, Brent, thank you!
--
resolution: - fixed
stage: needs patch - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16220
Brent Tubbs added the comment:
Updated patch with test attached.
--
Added file: http://bugs.python.org/file27608/wsgiref_close_plus_test.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16220
Graham Dumpleton added the comment:
That's right, the Django bug report I filed was actually for Django 1.3, which
didn't use wsgiref. I wasn't using Django 1.4 at the time so didn't bother to
check its new implementation based on wsgiref. Instead I just assumed wsgiref
would be right.
Brent Tubbs added the comment:
Patch attached.
I ran into this while trying to figure out why close() wasn't being called
while running the Django dev server, which inherits from wsgiref's BaseHandler.
So I'm also surprised that it's gone unnoticed so long.
Thanks for the quick attention
Changes by Jesús Cea Avión j...@jcea.es:
--
nosy: +jcea
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16220
___
___
Python-bugs-list mailing list
Jesús Cea Avión added the comment:
Brent, could you possibly provide also a test?. Something to integrate with the
standard testsuite that fails without your patch but passes with it.
--
___
Python tracker rep...@bugs.python.org
Jesús Cea Avión added the comment:
Your patch is trivial enough, I am OK to integrate it as is, but it would be
nice to verify that we are not reintroducing this bug in the future.
I know that writing a the test will be far more difficult that writing the
patch. You can try :).
Anyway I am
Graham Dumpleton added the comment:
Hmmm. Wonders if finally finding this was prompted in part by recent post about
this very issue. :-)
http://blog.dscpl.com.au/2012/10/obligations-for-calling-close-on.html
Also related is this issue from Django I highlighted long time ago.
Brent Tubbs added the comment:
You guessed it Graham! Bob Brewer pointed me to your post while I was fighting
with this, which led me to testing the behavior under various servers and
finding the wsgiref issue.
Current Django trunk doesn't have its own finish_response anymore for the dev
New submission from Brent Tubbs:
When a WSGI application returns an iterable that has a .close() method, the
server is supposed to call that method once the request has finished. The
wsgiref server does not do this when a client disconnects from a streaming
response.
The attached script
Changes by Brent Tubbs brent.tu...@gmail.com:
--
title: wsgiref does not call close() on iterable response when client -
wsgiref does not call close() on iterable response
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16220
Antoine Pitrou added the comment:
This sounds like a reasonable expectation. Do you want to provide a patch?
--
nosy: +pitrou, pje
stage: - needs patch
type: - behavior
versions: +Python 3.2, Python 3.3, Python 3.4
___
Python tracker
Phillip J. Eby added the comment:
FYI, this looks like a bug in wsgiref.handlers.BaseHandler.finish_response(),
which should probably be using a try/finally to ensure .close() gets called.
(Which would catch a failed write() to the client.)
I'm kind of amazed this has gone undetected this
15 matches
Mail list logo
