RFC Errata
Found 5 records.
Status: Verified (1)
RFC 7234, "Hypertext Transfer Protocol (HTTP/1.1): Caching", June 2014
Note: This RFC has been obsoleted by RFC 9111
Source of RFC: httpbis (wit)
Errata ID: 4674
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vasiliy Faronov
Date Reported: 2016-04-21
Verifier Name: Alexey Melnikov
Date Verified: 2016-04-26
Section 5.4 says:
When sending a no-cache request, a client ought to include both the
pragma and cache-control directives, unless Cache-Control: no-cache
is purposefully omitted to target other Cache-Control response
^^^^^^^^
directives at HTTP/1.1 caches.
It should say:
When sending a no-cache request, a client ought to include both the
pragma and cache-control directives, unless Cache-Control: no-cache
is purposefully omitted to target other Cache-Control request
^^^^^^^
directives at HTTP/1.1 caches.
Notes:
"other Cache-Control response directives" was probably intended to be "other Cache-Control request directives," because a request cannot have response directives.
Status: Held for Document Update (1)
RFC 7234, "Hypertext Transfer Protocol (HTTP/1.1): Caching", June 2014
Note: This RFC has been obsoleted by RFC 9111
Source of RFC: httpbis (wit)
Errata ID: 6279
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Todd Greer
Date Reported: 2020-09-04
Held for Document Update by: Francesca Palombini
Date Held: 2021-04-29
Section 4.2.4 says:
A cache MUST NOT generate a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache directive, a "must-revalidate" cache-response-directive, or an applicable "s-maxage" or "proxy-revalidate" cache-response-directive; see Section 5.2.2).
It should say:
A cache MUST NOT generate a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-cache" cache directive, a "must-revalidate" cache-response-directive, or an applicable "s-maxage" or "proxy-revalidate" cache-response-directive; see Section 5.2.2).
Notes:
The examples of directives that prohibit stale responses includes "no-store", but the definitions of "no-store" in 5.2.1.5 and 5.2.2.3 don't prohibit serving stale responses, and there is no other mention in RFC 7234 (or elsewhere) of "no-store" prohibiting serving stale responses.
If a "no-store" request directive is intended to prohibit serving stale responses, 5.2.1.5 should say so. (The question is meaningless for "no-store" response directives, since those should never be found in a cache.)
Status: Rejected (3)
RFC 7234, "Hypertext Transfer Protocol (HTTP/1.1): Caching", June 2014
Note: This RFC has been obsoleted by RFC 9111
Source of RFC: httpbis (wit)
Errata ID: 5564
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Adams
Date Reported: 2018-11-27
Rejected by: Alexey Melnikov
Date Rejected: 2019-03-25
Section 4.2.4 says:
A cache MUST NOT send stale responses unless it is disconnected (i.e., it cannot contact the origin server or otherwise find a forward path) or doing so is explicitly allowed (e.g., by the max-stale request directive; see Section 5.2.1).
It should say:
A cache SHOULD NOT send stale responses unless it is disconnected (i.e., it cannot contact the origin server or otherwise find a forward path) or doing so is explicitly allowed (e.g., by the max-stale request directive; see Section 5.2.1). A cache MAY send stale responses if a cache-control extension for stale content such as "stale-while-revalidate" is used (see RFC5861).
Notes:
The original text seems to conflict with https://tools.ietf.org/html/rfc5861#section-3
3. The stale-while-revalidate Cache-Control Extension
When present in an HTTP response, the stale-while-revalidate Cache-
Control extension indicates that caches MAY serve the response in
which it appears after it becomes stale, up to the indicated number
of seconds.
stale-while-revalidate = "stale-while-revalidate" "=" delta-seconds
If a cached response is served stale due to the presence of this
extension, the cache SHOULD attempt to revalidate it while still
serving stale responses (i.e., without blocking).
See also https://stackoverflow.com/questions/53324538/rest-low-latency-how-should-i-reply-to-a-get-while-an-upload-is-pending
--VERIFIER NOTES--
Mark Nottingham wrote:
Extensions are explicitly allowed to override requirements, and
making this a SHOULD would be too confusing (as many would read it as
"optional").
Errata ID: 4479
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Florian Best
Date Reported: 2015-09-20
Rejected by: Barry Leiba
Date Rejected: 2015-09-20
Section 5.3 says:
The Expires value is an HTTP-date timestamp, as defined in <a href="#section-7.1.1.1">Section</a> <a href="#section-7.1.1.1">7.1.1.1</a> of [<a href="./rfc7231" title=""Hypertext Transfer Protocol (HTTP/1.1) : Semantics and Content"">RFC7231</a>].
It should say:
The Expires value is an HTTP-date timestamp, as defined in <a href="./rfc7231#section-7.1.1.1">Section</a> <a href="./rfc7231#section-7.1.1.1">7.1.1.1</a> of [<a href="./rfc7231" title=""Hypertext Transfer Protocol (HTTP/1.1) : Semantics and Content"">RFC7231</a>].
Notes:
The anchor should link to RFC 7231. It links to the not-existing section in RFC 7234 itself.
--VERIFIER NOTES--
The links are not in the RFCs, but in the HTML tools rendering. The errata system isn't for that.
Errata ID: 4616
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Brian Chang
Date Reported: 2016-02-08
Rejected by: Alexey Melnikov
Date Rejected: 2017-02-23
Throughout the document, when it says:
(See Section 3.2 for additional details related to the use of public in response to a request containing Authorization, and Section 3 for details of how public affects responses that would normally not be stored, due to their status codes not being defined as cacheable by default; see Section 4.2.2.) has a status code that is defined as cacheable by default (see Section 4.2.2), or
It should say:
(See Section 3.2 for additional details related to the use of public in response to a request containing Authorization, and Section 3 for details of how public affects responses that would normally not be stored, due to their status codes not being defined as cacheable by default; see Section 6.1 of [RFC7231].) has a status code that is defined as cacheable by default (see Section 6.1 of [RFC7231]), or
Notes:
Section 4.2.2 is titled "Calculating Heuristic Freshness" but is referenced in the original text when talking about status codes. This is confusing despite having a reference to Section 6.1 of RFC7231 buried within the text.
There are other references to 4.2.2 as well, but those actually talk about heuristic freshness.
--VERIFIER NOTES--
See HTTPBIS mailing list discussion.