Chrome 110+ fetch cancellation: connection teardown after header receipt

Context

Chrome 110 added AbortSignal.timeout() as a standard way to enforce fetch deadlines. The Fetch Standard leaves the exact moment of connection teardown implementation-defined, creating a compatibility boundary where Chrome's behavior diverges from Firefox and Safari when a request is aborted after response headers have been delivered but before the body is consumed.

Goal

Determine whether Chrome reliably closes the underlying TCP connection when AbortController.abort() is called (or AbortSignal.timeout() fires) after headers arrive, and whether the current behavior matches the developer expectation that the network request is fully cancelled.

Constraints and uncertainty

• Chrome may keep the socket open to allow potential body reading, which can leak sockets and stall connection pools under high cancellation rates.
• DevTools Network panel shows "canceled" status, but chrome://net-internals/#sockets may reveal the socket remains in TIME_WAIT or is reused.
• Service workers exhibit a related gap: aborting a fetch inside a fetch event handler does not reliably cancel the outgoing request.
• Workarounds such as keepalive: false or immediate abort after header receipt are not guaranteed to force connection closure.

Questions

1. At what precise point in the fetch lifecycle does Chrome 110–120 release the socket when AbortSignal.timeout() expires after headers are received?
2. Does setting keepalive: false on the request change the teardown behavior in this scenario?
3. Are there any Chrome flags or enterprise policies that force immediate connection closure on abort?