This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author martin.panter
Recipients Yuri.Bochkarev, agriffis, alanjds, amak, cananian, demian.brecht, icordasc, jcea, jhylton, martin.panter, mhammond, orsenthil, r.david.murray, rbcollins
Date 2015-01-20.06:22:45
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1421734965.77.0.163709636319.issue3566@psf.upfronthosting.co.za>
In-reply-to
Content
Yeah I’m happy to put a patch together, once I have an idea of the details.

I’d also like to understand your scenario that would mislead the user to believe that the connection has been closed when it actually hasn’t. Can you give a concrete example or demonstration?

Given your misbehaving flow:

1. Client connects to server or proxy (possibly through a tunnel) and sends request; server/proxy accepts connection and possibly reads request
2. Server/proxy intends to send a response, but doesn't for any number of reasons (bug, still in development, etc)
3. The connection is not closed and subsequent requests may succeed

I would expect the client would still be waiting to read the status line of the response that was never sent in step 2. Eventually the server _would_ probably drop the connection (so ConnectionClosed would not be misleading), or the client would time it out (a different error would be raised).
History
Date User Action Args
2015-01-20 06:22:45martin.pantersetrecipients: + martin.panter, jhylton, mhammond, jcea, orsenthil, amak, rbcollins, cananian, r.david.murray, alanjds, agriffis, icordasc, demian.brecht, Yuri.Bochkarev
2015-01-20 06:22:45martin.pantersetmessageid: <1421734965.77.0.163709636319.issue3566@psf.upfronthosting.co.za>
2015-01-20 06:22:45martin.panterlinkissue3566 messages
2015-01-20 06:22:45martin.pantercreate