http.client.HTTPConnection.connect() leaks the socket when setting TCP_NODELAY fails (EINVAL on macOS after a reset)
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 77.2k
- Forks
- 35.9k
- PR merge metrics
- PR metrics pending
Description
Bug report
Bug description:
http.client.HTTPConnection.connect() creates the socket, then sets TCP_NODELAY on it:
self.sock = self._create_connection(
(self.host,self.port), self.timeout, self.source_address)
# Might fail in OSs that don't implement TCP_NODELAY
try:
self.sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)
except OSError as e:
if e.errno != errno.ENOPROTOOPT:
raise
If setsockopt() fails with anything other than ENOPROTOOPT, the error propagates with self.sock still holding the open, connected socket. A caller that drops the connection object then leaks the socket:
ResourceWarning: unclosed <socket.socket fd=4, family=2, type=1, proto=6, laddr=('127.0.0.1', 62584), raddr=('127.0.0.1', 62583)>
This is not hypothetical. On macOS, setsockopt(TCP_NODELAY) raises EINVAL once the peer has reset the connection. Racing a server that accepts and immediately closes with SO_LINGER set to zero (an RST) against a client that connects and sets TCP_NODELAY, 299 of 400 attempts on macOS 26 raised OSError(22, 'Invalid argument') from setsockopt(), one raised ECONNRESET, and 100 succeeded.
That is exactly the scenario of test_ssl.TestPreHandshakeClose.test_https_client_non_tls_response_ignored, whose server responds and resets the connection right after accepting. When the reset wins the race, connect() raises from setsockopt() instead of from the TLS handshake the test expects, and the plain socket is never closed. The test still passes (it only requires an OSError), but the socket is finalized after the test method returns, and regrtest reports the module as "env changed". Seen on the macOS x86-64 CI job of 374851f3db, in both the initial run and the rerun: https://github.com/python/cpython/actions/runs/33514119791/job/99876792339
test_https_client_non_tls_response_ignored (test.test_ssl.TestPreHandshakeClose.test_https_client_non_tls_response_ignored) ... Warning -- Unraisable exception
Exception ignored while finalizing socket <socket.socket fd=6, family=2, type=1, proto=6, laddr=('127.0.0.1', 49773)>:
ResourceWarning: unclosed <socket.socket fd=6, family=2, type=1, proto=6, laddr=('127.0.0.1', 49773)>
ok
The leaked object is a plain socket.socket, not an ssl.SSLSocket, which is what shows the failure happened before wrap_socket() took the file descriptor over: the only step in between that can raise while leaving self.sock assigned is that setsockopt() call. gh-110011 lists this test's ResourceWarning among others but does not identify the cause.
_tunnel() already handles its own connect-time failure by calling self.close() before raising. connect() should do the same when TCP_NODELAY cannot be set. I have a PR with the fix and a test.
CPython versions tested on:
CPython main branch
Operating systems tested on:
macOS
Linked PRs
- gh-157175
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at http.client.HTTPConnection.connect(), focusing on the TCP_NODELAY setsockopt() failure path and how _tunnel() handles connect-time errors. Review test.test_ssl.TestPreHandshakeClose.test_https_client_non_tls_response_ignored and its ResourceWarning behavior. Done means the socket is closed when setting TCP_NODELAY fails and the relevant test passes without an unclosed-socket warning.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend, networking
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 25/100