homepage

tl; dr I agree to ignore ECONNRESET-like errors on socket.shutdown() and sock.close().
I'm not sure that I understand *exactly* the problem here. In which case closing a socket fails with ECONNRESET? Can it mean that the last write() was buffered and failed?
If socket.send() is blocking, I expect that send() gets the ECONNRESET error.
If socket.send() is non-blocking, the application has to be very carefully written to handle many kinds of errors.
From a high lever point of view, I don't think that ECONNRESET is interested. I expect that a protocol at the application level doesn't rely on ECONNRESET, but a command like "QUIT". No?
For a file on disk, it's different, since write() is always buffered and close() has to flush pending write on disk.
For a network protocol, loosing the connection, loosing data, etc. is something "normal", not something execptional. That's why there are application-level commands to close cleanly a connection.
Ok, now for SSL sockets... Is it also ok to ignore ECONNRESET on sock.close() for an SSL socket?
--
ECONNRESET can occur on sock.close(), but not only: see bpo-30329, shutdown() fails can ENOTCONN on UNIX or WSAEINVAL on Windows. I modified poplib and imaplib recently to handle WSAEINVAL:
commit 83a2c2879839da2e10037f5e4af1bd1dafbf1a52
Author: Victor Stinner <victor.stinner@gmail.com>
Date: Mon May 15 17:33:45 2017 +0200
 bpo-30329: Catch Windows error 10022 on shutdown() (#1538)
 
 Catch the Windows socket WSAEINVAL error (code 10022) in imaplib and
 poplib on shutdown(SHUT_RDWR): An invalid operation was attempted
 
 This error occurs sometimes on SSL connections.