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.