Author r.david.murray
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:43:45
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I think that in other stdlib networking modules, a connection closed error is raised when an operation is attempted on a closed connection.  For example, in smtplib, the server may return an error code and then (contrary to the RFC) close the connection.  We fixed a bug in smtplib where this was mishandled (the error code was lost and SMTPServerDisconnected was raised instead).  Now we return the error code, and the *next* operation on the connection gets the connection closed error.

I think this is a good model, but I'm not sure if/how it can be applied here.  That is, if the connection has been closed, I think an operation attempted on the connection should raise an exception that makes it clear that the connection is closed (in the case of some stdlib modules, that may be a socket level exception for the operation on the closed socket).

I think the remote server writing a blank line to the socket is a very different thing from the remote server closing the connection without writing anything, so I may be misunderstanding something here.  Note that handling this is potentially more complicated with https, since in that case we have a wrapper around the socket communication that has some buffering involved.

But also note that if a new exception is introduced this becomes a feature and by our normal policies can only go into 3.5.
Date User Action Args
2015-01-20 06:43:45r.david.murraysetrecipients: + r.david.murray, jhylton, mhammond, jcea, orsenthil, amak, rbcollins, cananian, alanjds, agriffis, martin.panter, icordasc, demian.brecht, Yuri.Bochkarev
2015-01-20 06:43:45r.david.murraysetmessageid: <>
2015-01-20 06:43:45r.david.murraylinkissue3566 messages
2015-01-20 06:43:45r.david.murraycreate