Repository navigation
fix(http2): ignore PRIORITY and unknown frames on streams and reject non-zero stream control frames - #2006
Conversation
3b76f21 to
10b0ced
Compare
10b0ced to
12f71c3
Compare
12f71c3 to
6c17792
Compare
6c17792 to
8428322
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 |
…non-zero stream control frames > [!NOTE] > This PR was generated by an AI coding agent (Jetski) on behalf of @mosuem. ### Summary Per **RFC 9113**: - **Section 4.1 (Frame Format)**: *"Implementations MUST ignore and discard frames of unknown types."* - **Section 6.3 (`PRIORITY`)**: *"The `PRIORITY` frame can be sent on a stream in any state, including idle or closed streams."* - **Section 6.5 (`SETTINGS`), Section 6.7 (`PING`), Section 6.8 (`GOAWAY`)**: `SETTINGS`, `PING`, and `GOAWAY` frames apply to the entire connection and MUST be associated with stream `0x0`; receiving one with a non-zero stream identifier MUST be treated as a connection error of type `PROTOCOL_ERROR`. Previously: 1. `Connection._handleFrameImpl` dispatched any frame with `header.streamId != 0` to `_streams.processStreamFrame`, so a `SETTINGS`, `PING`, or `GOAWAY` frame with `streamId != 0` was treated as a stream error (`RST_STREAM(STREAM_CLOSED)`) instead of a connection-level `PROTOCOL_ERROR` (`GOAWAY(PROTOCOL_ERROR)`). 2. `StreamHandler._processStreamFrameInternal` threw `ProtocolException('Unsupported frame type ...')` (terminating the entire connection with `GOAWAY(PROTOCOL_ERROR)`) when a `PriorityFrame` or `UnknownFrame` arrived on an open stream, and threw `StreamClosedException` (sending `RST_STREAM(STREAM_CLOSED)`) when an `UnknownFrame` arrived on an idle or closed stream. Browsers and proxies that send `PRIORITY` frames on open streams therefore lost the whole connection. ### Changes - **`lib/src/connection.dart`**: Reject `SettingsFrame`, `PingFrame`, and `GoawayFrame` with `header.streamId != 0` via `ProtocolException` before stream dispatch. - **`lib/src/streams/stream_handler.dart`**: Ignore `PriorityFrame` and `UnknownFrame` on open streams, and on idle and closed streams (previously only `PriorityFrame` was ignored there). Not changed (possible follow-up): an ignored `PRIORITY`/unknown frame on an idle peer-initiated stream still advances `_highestStreamIdReceived`, which feeds the `last-stream-id` of a later `GOAWAY` (RFC 9113 Section 6.8). That is pre-existing behavior. ### Test Verification (Fails Before $\rightarrow$ Passes After) Added two regression tests in `test/server_test.dart`: - `ignores-priority-and-unknown-frames-on-open-and-idle-streams` - `rejects-control-frames-with-nonzero-stream-id` **Before fix:** ```text 00:00 +0 -1: server-tests normal ignores-priority-and-unknown-frames-on-open-and-idle-streams [E] HTTP/2 error: Connection error: Connection is being forcefully terminated. (errorCode: 1) 00:00 +0 -2: server-tests client-errors rejects-control-frames-with-nonzero-stream-id [E] Expected: <Instance of 'GoawayFrame'> with `errorCode`: <1> Actual: <Instance of 'RstStreamFrame'> Which: is not an instance of 'GoawayFrame' ``` **After fix:** ```text 00:00 +2: All tests passed! ```
8428322 to
2867462
Compare
Note
This PR was generated by an AI coding agent (Jetski) on behalf of @mosuem.
Summary
Per RFC 9113:
PRIORITY): "ThePRIORITYframe can be sent on a stream in any state, including idle or closed streams."SETTINGS), Section 6.7 (PING), Section 6.8 (GOAWAY):SETTINGS,PING, andGOAWAYframes apply to the entire connection and MUST be associated with stream0x0; receiving one with a non-zero stream identifier MUST be treated as a connection error of typePROTOCOL_ERROR.Previously:
Connection._handleFrameImpldispatched any frame withheader.streamId != 0to_streams.processStreamFrame, so aSETTINGS,PING, orGOAWAYframe withstreamId != 0was treated as a stream error (RST_STREAM(STREAM_CLOSED)) instead of a connection-levelPROTOCOL_ERROR(GOAWAY(PROTOCOL_ERROR)).StreamHandler._processStreamFrameInternalthrewProtocolException('Unsupported frame type ...')(terminating the entire connection withGOAWAY(PROTOCOL_ERROR)) when aPriorityFrameorUnknownFramearrived on an open stream, and threwStreamClosedException(sendingRST_STREAM(STREAM_CLOSED)) when anUnknownFramearrived on an idle or closed stream. Browsers and proxies that sendPRIORITYframes on open streams therefore lost the whole connection.Changes
lib/src/connection.dart: RejectSettingsFrame,PingFrame, andGoawayFramewithheader.streamId != 0viaProtocolExceptionbefore stream dispatch.lib/src/streams/stream_handler.dart: IgnorePriorityFrameandUnknownFrameon open streams, and on idle and closed streams (previously onlyPriorityFramewas ignored there).Not changed (possible follow-up): an ignored
PRIORITY/unknown frame on an idle peer-initiated stream still advances_highestStreamIdReceived, which feeds thelast-stream-idof a laterGOAWAY(RFC 9113 Section 6.8). That is pre-existing behavior.Test Verification (Fails Before$\rightarrow$ Passes After)
Added two regression tests in
test/server_test.dart:ignores-priority-and-unknown-frames-on-open-and-idle-streamsrejects-control-frames-with-nonzero-stream-idBefore fix:
After fix: