Chrome 110+ fetch cancellation: connection teardown after header receipt

Direct answer

Chrome does not guarantee that AbortController.abort() or AbortSignal.timeout() closes the underlying TCP/QUIC connection when the signal fires after response headers are received. The Fetch Standard only requires the fetch promise to reject with an AbortError and the response body stream to be errored; it does not define a network teardown point. “Fully cancelled at the socket level” is therefore a developer expectation, not a spec guarantee.

Correcting the version premise

AbortSignal.timeout() did not arrive in Chrome 110; it shipped in earlier releases (Chrome 103+). The abort-after-header behavior is not specific to a 110 boundary, so you should test on current stable or beta rather than gating logic on a version check.

What actually happens to the connection

• HTTP/2 and HTTP/3: Chrome resets only the affected stream (e.g., RST_STREAM) and keeps the underlying connection in the pool for reuse. The socket stays open by design.
• HTTP/1.1: An unread response body normally prevents connection reuse. Chrome will typically close or drain that connection, but the exact release point is implementation-defined and is not synchronized with the AbortError timestamp.

In short, there is no precise lifecycle moment at which Chrome 110–120 releases the socket after headers. The timing depends on the protocol, the connection pool state, and the browser build.

Does keepalive: false change teardown?

No. keepalive: false is the default. The flag only controls whether a request may continue after the document is unloaded (similar to sendBeacon semantics). It does not affect connection pooling and does not force a socket to close when an abort fires after headers.

Are there flags or policies forcing immediate closure?

There is no documented Chrome command-line flag or enterprise policy whose purpose is to force immediate TCP/QUIC teardown on fetch abort. Teardown is decided by the network service’s connection pool and the protocol rules. Do not expect a switch to change this behavior.

How to verify on your build

DevTools showing “canceled” only reflects the renderer promise state; it is not proof that the socket closed. Use a NetLog capture instead:

1. Open chrome://net-export and start logging.
2. Serve headers immediately, then delay the body. Abort after headers over both HTTP/1.1 and HTTP/2.
3. Stop the log and filter by the request’s socket ID. Look for SOCKET_CLOSE and FIN/RST events at abort time versus after body completion.
4. Compare with a second request to see whether the same connection is reused.

Service worker caveat

Inside a service worker fetch handler, a client-side abort does not reliably cancel the worker’s outgoing request. The worker can continue reading the body, so the socket may stay busy independently of the page’s AbortError.

Review note: Exact release timing across Chrome 110–120 is implementation-defined and version-sensitive. Re-verify on current stable/beta before relying on it.