RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 5 records.

Status: Verified (1)

RFC 7234, "Hypertext Transfer Protocol (HTTP/1.1): Caching", June 2014

Source of RFC: httpbis (app)

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

Source of RFC: httpbis (app)

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

Source of RFC: httpbis (app)

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="&quot;Hypertext Transfer Protocol (HTTP/1.1)
   : Semantics and Content&quot;">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="&quot;Hypertext Transfer Protocol (HTTP/1.1)
   : Semantics and Content&quot;">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.

Report New Errata