I don't think this is a correct report. In H3 push IDs are their own namespace
> A server SHOULD use push IDs sequentially, beginning from zero. There is no concept of using a wrong stream ID for push IDs. When a push promise is fulfilled, a server initiates a new unidirectional stream with a stream type header indicating its of push type, then followed by the push ID. Cheers Lucas On Thu, Nov 28, 2024, at 11:01, RFC Errata System wrote: > The following errata report has been submitted for RFC9114, > "HTTP/3". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid8190 > > -------------------------------------- > Type: Technical > Reported by: Cory Benfield <[email protected]> > > Section: 7.2.6 > > Original Text > ------------- > The GOAWAY frame is always sent on the control stream. In the > server-to-client direction, it carries a QUIC stream ID for a client- > initiated bidirectional stream encoded as a variable-length integer. > A client MUST treat receipt of a GOAWAY frame containing a stream ID > of any other type as a connection error of type H3_ID_ERROR. > > In the client-to-server direction, the GOAWAY frame carries a push ID > encoded as a variable-length integer. > > > Corrected Text > -------------- > The GOAWAY frame is always sent on the control stream. In the > server-to-client direction, it carries a QUIC stream ID for a client- > initiated bidirectional stream encoded as a variable-length integer. > A client MUST treat receipt of a GOAWAY frame containing a stream ID > of any other type as a connection error of type H3_ID_ERROR. > > In the client-to-server direction, the GOAWAY frame carries a push ID > encoded as a variable-length integer. A server MUST treat receipt of > a GOAWAY frame containing a stream ID of any other type as a > connection error of type H3_ID_ERROR. > > Notes > ----- > The MUST requiring a stream error on an invalid stream ID was missing in the > client-to-server direction. This is related to erratum 7780, and likely > entered the spec for the same reason. > > Instructions: > ------------- > This erratum is currently posted as "Reported". (If it is spam, it > will be removed shortly by the RFC Production Center.) Please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > will log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC9114 (draft-ietf-quic-http-34) > -------------------------------------- > Title : HTTP/3 > Publication Date : June 2022 > Author(s) : M. Bishop, Ed. > Category : PROPOSED STANDARD > Source : QUIC > Stream : IETF > Verifying Party : IESG >
