Re: [Technical Errata Reported] RFC7540 (4666)

As discussed on list, I think the best we can do here is to note that in many cases, it'd be desireable to mark this as explicitly uncacheable.

Recommend as REJECT or HOLD FOR UPDATE with the note above.

Cheers,

> On 13 Apr 2016, at 11:55 PM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
> 
> The following errata report has been submitted for RFC7540,
> "Hypertext Transfer Protocol Version 2 (HTTP/2)".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=7540&eid=4666
> 
> --------------------------------------
> Type: Technical
> Reported by: Vasiliy Faronov <vfaronov@gmail.com>
> 
> Section: 9.1.2
> 
> Original Text
> -------------
>   A 421 response is cacheable by default, i.e., unless otherwise
>   indicated by the method definition or explicit cache controls (see
>   Section 4.2.2 of [RFC7234]).
> 
> 
> Corrected Text
> --------------
>   [paragraph removed]
> 
> Notes
> -----
> The HTTP cache key (RFC 7234 Section 2) is based on the request URI, not on properties of the connection. Therefore, if a client were to cache a 421 response, it would then use this cached 421 to satisfy further requests to the same URI, before it has a chance to connect to an authoritative server.
> 
> With this paragraph removed, a 421 response is not cacheable by default, per RFC 7231 Section 6.1.
> 
> 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. 
> 
> --------------------------------------
> RFC7540 (draft-ietf-httpbis-http2-17)
> --------------------------------------
> Title               : Hypertext Transfer Protocol Version 2 (HTTP/2)
> Publication Date    : May 2015
> Author(s)           : M. Belshe, R. Peon, M. Thomson, 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, 26 April 2016 03:05:01 UTC