Repository navigation
fix(http2): never write RST_STREAM ahead of the stream's still-queued HEADERS - #2008
Conversation
079b3e0 to
c720a11
Compare
c720a11 to
34dfcb6
Compare
34dfcb6 to
81d7268
Compare
81d7268 to
262a8a3
Compare
PR HealthCoverage ✔️
This check for test coverage is informational (issues shown here will not fail the PR). This check can be disabled by tagging the PR with License Headers ✔️
All source files should start with a license header. Unrelated files missing license headers
This check can be disabled by tagging the PR with Breaking changes ✔️
This check can be disabled by tagging the PR with Unused Dependencies ✔️
For details on how to fix these, see dependency_validator. This check can be disabled by tagging the PR with API leaks ✔️The following packages contain symbols visible in the public API, but not exported by the library. Export these symbols or remove them from your publicly visible API.
This check can be disabled by tagging the PR with Changelog Entry ✔️
Changes to files need to be accounted for in their respective changelogs. This check can be disabled by tagging the PR with |
… HEADERS > [!NOTE] > This PR was generated by an AI coding agent (Jetski) on behalf of @mosuem. ### Summary `StreamHandler._terminateStream` (what `TransportStream.terminate()` ends up in) wrote the `RST_STREAM(CANCEL)` straight to the `FrameWriter`, bypassing `ConnectionMessageQueueOut`. If the stream's opening `HEADERS` were still sitting in that queue — because the socket was applying backpressure, or because the queue was head-of-line blocked behind flow-controlled `DATA` of another stream — the peer received `RST_STREAM` for a stream it had never seen, which is a connection error (RFC 9113 Section 6.4: *"RST_STREAM frames MUST NOT be sent for a stream in the "idle" state. If a RST_STREAM frame identifying an idle stream is received, the recipient MUST treat this as a connection error of type PROTOCOL_ERROR"*). A client cancelling a request shortly after starting it could thus take down the whole connection. ### Changes - **`lib/src/flowcontrol/connection_queues.dart`**: Add `ConnectionMessageQueueOut.cancelStreamMessages(streamId)`, which drops the stream's queued `DataMessage`s (they would be discarded by the peer anyway) and reports whether a `HeadersMessage` for the stream is still queued. - **`lib/src/streams/stream_handler.dart`**: In `_terminateStream`, enqueue a `ResetStreamMessage` behind the queued `HEADERS` when there are any; otherwise write the `RST_STREAM` directly as before. ### Test Verification (Fails Before $\rightarrow$ Passes After) Added `rst-stream-is-sent-after-queued-headers-of-the-stream` in `test/client_test.dart`. The test keeps the client's `FrameWriter` in its "would buffer" state (the server's `StreamIterator` pauses the frame stream after each frame, and that pause propagates synchronously into the client's `BufferedSink`), opens a stream and cancels it immediately, then checks the wire order. **Before fix:** ```text 00:00 +0 -1: client-tests client-errors rst-stream-is-sent-after-queued-headers-of-the-stream [E] Expected: <Instance of 'HeadersFrame'> with `streamId`: <3> Actual: <Instance of 'RstStreamFrame'> Which: is not an instance of 'HeadersFrame' ``` **After fix:** ```text 00:00 +1: All tests passed! ```
262a8a3 to
c3e3058
Compare
Note
This PR was generated by an AI coding agent (Jetski) on behalf of @mosuem.
Summary
StreamHandler._terminateStream(whatTransportStream.terminate()ends up in) wrote theRST_STREAM(CANCEL)straight to theFrameWriter, bypassingConnectionMessageQueueOut. If the stream's openingHEADERSwere still sitting in that queue — because the socket was applying backpressure, or because the queue was head-of-line blocked behind flow-controlledDATAof another stream — the peer receivedRST_STREAMfor a stream it had never seen, which is a connection error (RFC 9113 Section 6.4: "RST_STREAM frames MUST NOT be sent for a stream in the "idle" state. If a RST_STREAM frame identifying an idle stream is received, the recipient MUST treat this as a connection error of type PROTOCOL_ERROR"). A client cancelling a request shortly after starting it could thus take down the whole connection.Changes
lib/src/flowcontrol/connection_queues.dart: AddConnectionMessageQueueOut.cancelStreamMessages(streamId), which drops the stream's queuedDataMessages (they would be discarded by the peer anyway) and reports whether aHeadersMessagefor the stream is still queued.lib/src/streams/stream_handler.dart: In_terminateStream, enqueue aResetStreamMessagebehind the queuedHEADERSwhen there are any; otherwise write theRST_STREAMdirectly as before.Test Verification (Fails Before$\rightarrow$ Passes After)
Added
rst-stream-is-sent-after-queued-headers-of-the-streamintest/client_test.dart. The test keeps the client'sFrameWriterin its "would buffer" state (the server'sStreamIteratorpauses the frame stream after each frame, and that pause propagates synchronously into the client'sBufferedSink), opens a stream and cancels it immediately, then checks the wire order.Before fix:
After fix: