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 demian.brecht
Recipients Yuri.Bochkarev, agriffis, alanjds, amak, cananian, demian.brecht, gregory.p.smith, icordasc, jcea, jhylton, martin.panter, mhammond, orsenthil
Date 2015-01-16.02:00:52
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1421373654.64.0.427597433646.issue3566@psf.upfronthosting.co.za>
In-reply-to
Content
Trying to reproduce this on my own in 3.5, 2.7 and 2.5 yields a ConnectionResetError (ECONNRESET), which seems to be correct. That said, this could be due to varying TCP implementations on the server so might still be valid. It could also be due to an older kernel which has been fixed since this was originally reported. Is this still reproducible? If so, can an example be provided?

If the error as written is reproducible, I think that the error message should be fixed, but I'm not so sure that any more than that should be done.


As far as the RFC goes, I think the MUST clause pointed out can be left to the interpretation of the reader. You /could/ consider http.client as the client, but you could also consider the application that a user is interacting with as the client.

Offhand, I think that the library as it is does the right thing in allowing the application code to handle the exceptions as it sees fit. Because http.client in its current state doesn't allow for request pipelining, retries from calling code should be trivial, if that is what the caller intends to do.
History
Date User Action Args
2015-01-16 02:00:54demian.brechtsetrecipients: + demian.brecht, jhylton, mhammond, gregory.p.smith, jcea, orsenthil, amak, cananian, alanjds, agriffis, martin.panter, icordasc, Yuri.Bochkarev
2015-01-16 02:00:54demian.brechtsetmessageid: <1421373654.64.0.427597433646.issue3566@psf.upfronthosting.co.za>
2015-01-16 02:00:54demian.brechtlinkissue3566 messages
2015-01-16 02:00:52demian.brechtcreate