RFC Errata
Found 4 records.
Status: Verified (2)
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: 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: Reported (2)
RFC 9114, "HTTP/3", June 2022
Source of RFC: quic (wit)
Errata ID: 7238
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Jaikiran Pai
Date Reported: 2022-11-04
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".
Errata ID: 7702
Status: Reported
Type: Technical
Publication Format(s) : HTML
Reported By: Lucas Pardue
Date Reported: 2023-11-15
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 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.
Notes:
HTTP/2 doesn't define PADDING frames