Repository navigation
refuse unsupported quic client streams without closing the connection - #229
Merged
Merged
Conversation
This was referenced Oct 12, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of #207. The broker closed the whole QUIC connection with
ERROR_PROTOCOL_L0for any client-opened bidirectional stream that was not a flow discard. MQoQ §9.10 says the acceptor checks the flow header and, if it is invalid or unsupported, aborts that stream with an error code. §11 keeps flow errors isolated so the connection survives.What changes:
ERROR_FLOW_REFUSED, the same code our client uses since refuse quic user-defined flows on server streams #204. Before, a unidirectional one was read as MQTT:14 02 68 69closed the connection as a malformed packet, and14 61 70 70was left open waiting for bytes.ERROR_BAD_FLOW_ID(§9.4, §9.10: an initiator/type mismatch on a data flow is a level 1 flow error). Before, a unidirectional one was accepted as a data flow.ERROR_STREAM_TYPE.ERROR_FLOW_REFUSED. Serving it on its own stream, as §9.1.2 requires for its acks and PINGRESP, is the next PR.ERROR_INCOMPLETE_PACKET, but once the client has finished a unidirectional stream nothing can be sent back on it.quic_flow_streams.rscovers each case. Against main, 7 of its 10 tests fail. The 3 that pass are the controls: a unidirectional data flow is still served, a discard ended by FIN is still answered with FIN, and a unidirectional flow ending inside a packet still keeps the session. The subscription test also checks that without a discard the aborted flow keeps receiving.