RFC Errata
Found 9 records.
Status: Verified (5)
RFC 9110, "HTTP Semantics", June 2022
Source of RFC: httpbis (wit)
Errata ID: 7138
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Yousouf Taghzouti
Date Reported: 2022-09-23
Verifier Name: Francesca Palombini
Date Verified: 2022-11-09
Section 12.5.1 says:
The media type quality factor associated with a given type is
determined by finding the media range with the highest precedence
that matches the type. For example,
Accept: text/*;q=0.3, text/plain;q=0.7, text/plain;format=flowed,
text/plain;format=fixed;q=0.4, */*;q=0.5
would cause the following values to be associated:
Table 5:
Media Type Quality Value
text/plain;format=flowed 1
text/plain 0.7
text/html 0.3
image/jpeg 0.5
text/plain;format=fixed 0.4
text/html;level=3 0.7
It should say:
The media type quality factor associated with a given type is
determined by finding the media range with the highest precedence
that matches the type. For example,
Accept: text/*;q=0.3, text/plain;q=0.7, text/plain;format=flowed,
text/plain;format=fixed;q=0.4, */*;q=0.5
would cause the following values to be associated:
Table 5:
Media Type Quality Value
text/plain;format=flowed 1
text/plain 0.7
text/html 0.3
image/jpeg 0.5
text/plain;format=fixed 0.4
text/html;level=3 0.3
Notes:
To illustrate how the media type quality factor associated with a given type is determined, the following example is given:
Accept: text/*;q=0.3, text/plain;q=0.7, text/plain;format=flowed, text/plain;format=fixed;q=0.4, */*;q=0.5
The last row of the result table (table 5) presenting the values to be associated cannot be deduced (MediaType: text/html;level=3, Quality Value: 0.7), since only "text/*;q=0.3" and "*/*;q=0.5" are possible values and as explained in the RFC "text/*;q=0.3" should take precedence.
In section 5.3.2 of RFC7231, a similar example is given, where the last row of the table is correct (text/html;level=3 | 0.7) since in that example the accept header contains (text/html;q=0.7).
Errata ID: 7306
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Julian Reschke
Date Reported: 2023-01-13
Verifier Name: Francesca Palombini
Date Verified: 2023-10-23
Section 14.1.1 says:
ranges-specifier = range-unit "=" range-set
range-set = 1#range-spec
range-spec = int-range
/ suffix-range
/ other-range
It should say:
ranges-specifier = range-unit "=" OWS range-set
range-set = 1#range-spec
range-spec = int-range
/ suffix-range
/ other-range
Notes:
The ABNF is inconsistent with one of the examples given in 14.1.2
bytes= 0-999, 4500-5499, -1000
The bug in the ABNF was likely introduced when converting away from "implied linear whitespace".
See also <https://github.com/whatwg/fetch/issues/1070#issuecomment-1361800123>.
Errata ID: 7419
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Dave Shawley
Date Reported: 2023-04-11
Verifier Name: Francesca Palombini
Date Verified: 2023-10-23
Section 8.3.2 says:
In the fields defined by this document, charset names appear either in parameters (Content-Type), or, for Accept-Encoding, in the form of a plain token.
It should say:
In the fields defined by this document, charset names appear either in parameters (Content-Type), or, for Accept-Charset, in the form of a plain token.
Notes:
Accept-Encoding is the preferred list of response content codings. Accept-Charset is the preferred list of response charsets.
Errata ID: 7109
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Gary Wilson Jr.
Date Reported: 2022-08-31
Verifier Name: Francesca Palombini
Date Verified: 2022-11-09
Section 15.4.9 says:
The 308 (Permanent Redirect) status code indicates that the target resource has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs.
It should say:
The 308 (Permanent Redirect) status code indicates that the target
resource has been assigned a new permanent URI and any future
references to this resource ought to use one of the enclosed URIs.
The user agent MUST NOT change the request method if it performs
an automatic redirection to that URI.
and/or add note as is present in RFC 7538, e.g.:
Note: This status code is similar to 301 (Moved Permanently)
(Section 15.4.2), except that it does not allow changing
the request method from POST to GET.
Notes:
The current text in this section for 308 Permanent Redirect does not include any mention of the user agent not changing the request method. I am suggesting that similar wording be used as in 15.4.8. 307 Temporary Redirect and/or a note added similar to the one present in RFC 7538 but excluded from this section's current text. Whichever is chosen, it would be good to make the wording/notes consistent across both the 307 and 308 status code sections.
Errata ID: 7105
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Tomoyuki Sahara
Date Reported: 2022-08-26
Verifier Name: Francesca Palombini
Date Verified: 2022-11-01
Section B.1. says:
B.1. Changes from RFC 2818 None.
It should say:
B.1. Changes from RFC 2818 The use of CN-ID has been deprecated.
Notes:
In RFC2818:
If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used.
CN-ID may be used (when a subjectAltName of type dNSName is not present).
In RFC9110:
A reference identity of type CN-ID MUST NOT be used by clients.
CN-ID is not used at all. It is a change from RFC2818.
Status: Reported (1)
RFC 9110, "HTTP Semantics", June 2022
Source of RFC: httpbis (wit)
Errata ID: 7870
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Kallus
Date Reported: 2024-03-24
Section 8.6 says:
Likewise, a sender MUST NOT forward a message with a Content-Length header field value that does not match the ABNF above, with one exception: a recipient of a Content-Length header field value consisting of the same decimal value repeated as a comma-separated list (e.g, "Content-Length: 42, 42") MAY either reject the message as invalid or replace that invalid field value with a single instance of the decimal value, since this likely indicates that a duplicate was generated or combined by an upstream message processor.
It should say:
Likewise, a sender MUST NOT send a message with a Content-Length header field value that does not match the ABNF above. A recipient of a Content-Length header field value consisting of the same decimal value repeated as a comma-separated list (e.g, "Content-Length: 42, 42") MAY either reject the message as invalid or replace that invalid field value with a single instance of the decimal value, since this likely indicates that a duplicate was generated or combined by an upstream message processor.
Notes:
This change aims to fix 2 issues with the text:
Issue #1
Recall the following from section 8.6:
> Likewise, a sender MUST NOT forward a message with a Content-Length header field value that does not match the ABNF above, ...
It wasn't immediately clear to me which of these was the intended meaning:
1. Upon receipt of a message with an invalid Content-Length value, senders MUST NOT forward the message.
2. Upon receipt of a message with an invalid Content-Length value, senders MUST NOT forward the message with the invalid value intact.
Mark Nottingham confirmed on GitHub that the intended meaning is option 2:
https://github.com/httpwg/http-core/issues/1113#issuecomment-1937914210
I propose that the word "forward" be changed to "send" to clear up the ambiguity.
Issue #2
We've just established that the intended meaning of the first half of the sentence in question is that malformed CL header values MUST NOT be forwarded intact.
An exception to this rule is (by definition) a situation in which invalid CL header values *are* permitted to be forwarded intact.
The "exception" described in the text does not allow for invalid header values to be forwarded intact, so it is a misuse of the word "exception."
To clear this up, I propose that the sentence be split in two, and that the word "exception" be removed.
Status: Rejected (3)
RFC 9110, "HTTP Semantics", June 2022
Source of RFC: httpbis (wit)
Errata ID: 7107
Status: Rejected
Type: Technical
Publication Format(s) : HTML
Reported By: James Synge
Date Reported: 2022-08-31
Rejected by: RFC Editor
Date Rejected: 2022-10-12
Section 6.5.1 says:
For example, the chunked transfer coding in HTTP/1.1 allows a trailer section to be sent after the content (Section 7.1.2 of [HTTP/1.1]).
It should say:
For example, the chunked transfer coding in HTTP/1.1 allows a trailer section to be sent after the content (Section ?.?.? of [HTTP/1.1]).
Notes:
Section 7.1.2 does not exist. It isn't clear to me which section is the intended target of the reference.
--VERIFIER NOTES--
Errata rejected per Julian Reschke. Section 7.1.2 does exist.
See <https://www.rfc-editor.org/rfc/rfc9112#section-7.1.2>.
Errata ID: 7599
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Justine Krejcha
Date Reported: 2023-08-11
Rejected by: Francesca Palombini
Date Rejected: 2023-10-23
Section 6.4.1 says:
All 1xx (Informational), 204 (No Content), and 304 (Not Modified) responses do not include content. All other responses do include content, although that content might be of zero length.
It should say:
All 1xx (Informational), 204 (No Content), 205 (Reset Content), and 304 (Not Modified) responses do not include content. All other responses do include content, although that content might be of zero length.
Notes:
Per section 15.3.6 (205 No Content), it says that servers MUST NOT generate a response. Section 6.4.1 says that "All 1xx, 204, and 304 response don't include content and others do." even though 205 response mustn't generate content.
--VERIFIER NOTES--
In rejecting this Errata report I note that the reported text is not an error, but a deliberate decision of the authors and working group.
Errata ID: 7530
Status: Rejected
Type: Editorial
Publication Format(s) : HTML
Reported By: Philippe Cloutier
Date Reported: 2023-05-29
Rejected by: RFC Editor
Date Rejected: 2023-07-07
Section 15.5.2. says:
The 401 (Unauthorized) status code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource.
It should say:
The 401 (Unauthorized) status code indicates that the request has not been processed because it lacks valid authentication credentials for the target resource.
Notes:
"applying a request" is not a standard expression. Usually, requests are "treated", "granted" or "processed".
This phrasing was imported in Apache Tomcat; thanks to Mark Thomas for pointing out it came from this RFC.
--VERIFIER NOTES--
A method is applied to a resource to have an effect that results in a response. Any web search on "method applied" will show you that it is quite common in standard English. The request has already been processed, at least partially, in order to make a decision that resulted in a 401 error