python / python/cpython

http.client.HTTPConnection.connect() leaks the socket when setting TCP_NODELAY fails (EINVAL on macOS after a reset)

Open
#157,174 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

stdlib type-bug
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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.