RFC Errata
Found 5 records.
Status: Verified (3)
RFC 9114, "HTTP/3", June 2022
Source of RFC: quic (wit)
Errata ID: 7014
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: David Schinazi
Date Reported: 2022-07-06
Verifier Name: Zaheduzzaman Sarker
Date Verified: 2022-09-27
Section 4.3.1 says:
":path": Contains the path and query parts of the target URI (the
"path-absolute" production and optionally a ? character (ASCII
0x3f) followed by the "query" production; see Sections 3.3 and 3.4
of [URI].
It should say:
":path": Contains the path and query parts of the target URI (the
"absolute-path" production and optionally a ? character (ASCII
0x3f) followed by the "query" production; see Section 4.1 of
[HTTP] and Section 3.4 of [URI].
Notes:
There is a conflict between RFC 9114 and RFCs 9110,9112,9113. RFC 9114 disallows paths that start with "//" whereas the others allow them. Research seems to indicate that this was not intentional. More details on the mailing list discussion: https://lists.w3.org/Archives/Public/ietf-http-wg/2022JulSep/0014.html
Errata ID: 7702
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Lucas Pardue
Date Reported: 2023-11-15
Verifier Name: Zaheduzzaman Sarker
Date Verified: 2025-03-19
Section 10.7 says:
Where HTTP/2 employs PADDING frames and Padding fields in other frames to make a connection more resistant to traffic analysis, HTTP/3 can either rely on transport-layer padding or employ the reserved frame and stream types discussed in Sections 7.2.8 and 6.2.3.
It should say:
Where HTTP/2 employs Padding fields in some types of frame to make a connection more resistant to traffic analysis, HTTP/3 can either rely on transport-layer padding or employ the reserved frame and stream types discussed in Sections 7.2.8 and 6.2.3.
Notes:
HTTP/2 doesn't define PADDING frames
Errata ID: 7780
Status: Verified
Type: Technical
Publication Format(s) : TEXT, HTML
Reported By: Lucas Pardue
Date Reported: 2024-01-24
Verifier Name: Francesca Palombini
Date Verified: 2024-01-29
Section 7.2.6 says:
The GOAWAY frame applies to the entire connection, not a specific stream. A client MUST treat a GOAWAY frame on a stream other than the control stream as a connection error of type H3_FRAME_UNEXPECTED.
It should say:
The GOAWAY frame applies to the entire connection, not a specific stream. An endpoint MUST treat a GOAWAY frame on a stream other than the control stream as a connection error of type H3_FRAME_UNEXPECTED.
Notes:
HTTP/3 originally only supported GOAWAY from server to client. In this PR we added the ability to also send GOAWAY from client to server https://github.com/quicwg/base-drafts/pull/3129/files. Unfortunately we didn't update the highlighted text to cover the situation where a server receives a GOAWAY on a different stream.
FWIW the implementation I am responsible for already applies the rule to request streams.
Status: Rejected (2)
RFC 9114, "HTTP/3", June 2022
Source of RFC: quic (wit)
Errata ID: 7238
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Jaikiran Pai
Date Reported: 2022-11-04
Rejected by: Francesca Palombini
Date Rejected: 2024-10-30
Section 4.2.2 says:
Because this limit is applied separately by each implementation that processes the message, messages below this limit are not guaranteed to be accepted.
It should say:
Because this limit is applied separately by each implementation that processes the message, messages above this limit are not guaranteed to be accepted.
Notes:
The section 4.2.2 specifies header size constraints and notes that implementations can send a SETTINGS frame with a SETTINGS_MAX_FIELD_SECTION_SIZE identifier to set a limit on the maximum size of the message header. Since this a maximum size, the sentence that states that intermediaries aren't guaranteed to accept a message below this limit seems odd and I think it should instead say "above this limit".
--VERIFIER NOTES--
The current RFC text is correct. The problem that is being described is where 1) a client sends a message smaller than MAX_FIELD_SECTION_SIZE and might expect that to work but 2) the server is an intermediary that needs to forward the message onto another server that, for example, has a smaller value for MAX_FIELD_SECTION_SIZE preventing this.
Any further clarification to this text, if any is needed, should be made via an update to this document. We encourage you to participate in suggesting improvement/clarifications by opening an issue on the spec issue tracker (https://github.com/quicwg) or in the mailing list: <quic@ietf.org>.
See https://mailarchive.ietf.org/arch/msg/quic/8E8kNJe1VGKEjotTl3IT2oZoGGo/
Errata ID: 8190
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, HTML
Reported By: Cory Benfield
Date Reported: 2024-11-28
Rejected by: Zaheduzzaman Sarker
Date Rejected: 2025-03-18
Section 7.2.6 says:
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.
It should say:
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.
--VERIFIER NOTES--
In H3 push IDs are their own namespace. 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.