NS_ERROR_NET_TIMEOUT and HTTP/2 stream termination in Necko

Question

When a fetch request is aborted via an AbortController in Firefox, the Necko networking component initiates a cancellation sequence. While the browser-side promise rejects immediately, the behavior of the underlying HTTP/2 stream remains inconsistent regarding the timing of resource cleanup.
nSpecifically, in high-latency environments, there is uncertainty whether an aborted HTTP/2 stream triggers an immediate RST_STREAM frame to free the multiplex slot, or if the stream remains open until the connection pool's idle timeout expires. This is particularly relevant when service workers intercept these requests, as the browser may cancel the network task independently of the worker's state.
nDoes Firefox send an immediate RST_STREAM when an HTTP/2 fetch is aborted via AbortController?How does the network.http.response-timeout preference affect the cleanup lifecycle of aborted streams on a multiplexed connection?

Tasadduq Burney · Answer

Answer
When a fetch is aborted via AbortController, Firefox sends an RST_STREAM frame immediately to terminate the HTTP/2 stream. The network.http.response-timeout preference does not influence this cleanup; it only controls how long the network layer waits for the first byte of a response.
Confirmed facts

An RST_STREAM frame is transmitted on the multiplexed connection as soon as the abort signal is processed by Necko.
The frame reclaims the stream ID, freeing the slot for other streams without closing the underlying TCP connection.
Changing network.http.response-timeout (e.g., via about:config) does not alter the timing of the RST_STREAM after an abort.

Likely explanation (subject to version)
In recent Gecko releases the abort path calls the HTTP/2 stream cancellation routine directly, which queues the RST_STREAM for immediate transmission. High latency may delay the actual wire appearance of the frame, but the browser‑side decision to send it is instantaneous. Service‑worker interception does not change this unless the worker’s own fetch is also aborted.
Verification steps

Open Firefox and navigate to about:config; set network.http.response-timeout to a low value (e.g., 500) and a high value (e.g., 30000) to confirm it does not affect abort behavior.
Enable logging or use Wireshark with filter http2 to capture traffic.
In the page console, create a fetch to a slow endpoint, attach an AbortController, and call abort() after a short delay.
Observe the captured packets: an RST_STREAM frame should appear shortly after the abort call, regardless of the timeout preference.
Optionally, visit about:networking#h2 to see the stream transition from open to closed immediately after abort.

Missing diagnostic detail
To be certain the behavior matches your environment, please confirm the Firefox/Gecko version you are testing (e.g., via about:support). Older versions may queue the RST_STREAM differently, which would change the recommendation.

NS_ERROR_NET_TIMEOUT and HTTP/2 stream termination in Necko

1 answer

Answer

Confirmed facts

Likely explanation (subject to version)

Verification steps

Missing diagnostic detail

Your perspective belongs here.

0 question comments