W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2016

Re: [Editorial Errata Reported] RFC7234 (4616)

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 9 Feb 2016 11:08:22 +1100
Cc: Roy Fielding <fielding@gbiv.com>, "Julian F. Reschke" <julian.reschke@greenbytes.de>, barryleiba@computer.org, me@brianchang.info, ietf-http-wg@w3.org
Message-Id: <95C7BA04-69C1-474D-B79E-7993269EEACD@mnot.net>
To: RFC Errata System <rfc-editor@rfc-editor.org>
4.2.2 explains "cacheable by default" in the context of HTTP caching.


> On 9 Feb 2016, at 11:05 am, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
> 
> The following errata report has been submitted for RFC7234,
> "Hypertext Transfer Protocol (HTTP/1.1): Caching".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=7234&eid=4616
> 
> --------------------------------------
> Type: Editorial
> Reported by: Brian Chang <me@brianchang.info>
> 
> Section: GLOBAL
> 
> Original Text
> -------------
> (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
> 
> Corrected Text
> --------------
> (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.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC7234 (draft-ietf-httpbis-p6-cache-26)
> --------------------------------------
> Title               : Hypertext Transfer Protocol (HTTP/1.1): Caching
> Publication Date    : June 2014
> Author(s)           : R. Fielding, Ed., M. Nottingham, Ed., J. Reschke, Ed.
> Category            : PROPOSED STANDARD
> Source              : Hypertext Transfer Protocol Bis APP
> Area                : Applications
> Stream              : IETF
> Verifying Party     : IESG
> 

--
Mark Nottingham   https://www.mnot.net/
Received on Tuesday, 9 February 2016 00:09:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 22 March 2016 12:47:11 UTC