Message297544
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. |
|
Date |
User |
Action |
Args |
2017-07-03 08:28:10 | vstinner | set | recipients:
+ vstinner, janssen, pitrou, christian.heimes, alex, martin.panter, dstufft |
2017-07-03 08:28:10 | vstinner | set | messageid: <1499070490.33.0.0125454606894.issue30319@psf.upfronthosting.co.za> |
2017-07-03 08:28:10 | vstinner | link | issue30319 messages |
2017-07-03 08:28:09 | vstinner | create | |
|