RFC Errata
Found 3 records.
Status: Verified (1)
RFC 9112, "HTTP/1.1", June 2022
Source of RFC: httpbis (wit)
Errata ID: 7744
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: sequpt
Date Reported: 2023-12-31
Verifier Name: RFC Editor
Date Verified: 2024-01-03
Section 1.2 says:
obs-text = <obs-text, see [HTTP], Section 5.6.4>
It should say:
obs-text = <obs-text, see [HTTP], Section 5.5>
Notes:
'obs-text' is used in the rules defined in 5.6.4 but is only defined in 5.5.
This error also appears in 'Appendix A. Collected ABNF'.
Status: Rejected (2)
RFC 9112, "HTTP/1.1", June 2022
Source of RFC: httpbis (wit)
Errata ID: 7214
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Niklas Wolber
Date Reported: 2022-10-31
Rejected by: Francesca Palombini
Date Rejected: 2022-11-09
Section 1.2 says:
The following core rules are included by reference, as defined in [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any visible [USASCII] character).
It should say:
The following core rules are included by reference, as defined in [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG (hexadecimal 0-9/A-F), HTAB (horizontal tab), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any visible [USASCII] character).
Notes:
Rule HEXDIG from RFC5234 is
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
excluding lower-case letters.
--VERIFIER NOTES--
RFC 5234 section 2.3 says: ABNF strings are case insensitive and the character set for these strings is US-ASCII.
Errata ID: 7633
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Amos Jeffries
Date Reported: 2023-09-06
Rejected by: Francesca Palombini
Date Rejected: 2023-11-07
Section 2.2 says:
Although the line terminator for the start-line and fields is the sequence CRLF, a recipient MAY recognize a single LF as a line terminator and ignore any preceding CR.
It should say:
Although the line terminator for the start-line, fields, chunk and last-chunk is the sequence CRLF, a recipient MAY recognize a single LF as a line terminator and ignore any preceding CR.
Notes:
chunked encoding (section 6.3) uses CRLF for line/framing delimiters in the same manner as other HTTP message sections. But these lines are not listed as a possible sites of bare-LF line terminator. Which makes for an unnecessary parser exception and complicates possible request smuggling robustness between implementations.
--VERIFIER NOTES--
The difference was intentional. A chunked parser is not a start line or field parser (it is a message body parser) and it is supposed to be less forgiving because it does not have to retain backwards compatibility with 1.0 parsers.
Hence, bare LF around the chunk sizes would be invalid and should result in the connection being marked as invalid.
In any case, suggestions to further hardening of the chunked parser would have to be defined in that section, and would need to be achieved through a consensus document, not in an errata report.