Re: Cacheability of 421 (Misdirected Request)

[Mark Nottingham <[e-mail]>]

Hi,

> On 11 Apr 2016, at 2:19 PM, Vasiliy Faronov <[e-mail]> wrote:
> 
> Hi,
> 
> RFC 7540 Section 9.1.2 says that responses with status code 421
> (Misdirected Request) are cacheable by default. I think this is wrong.
> HTTP cache key is based on the request URI, so 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
> the right server.
> 
> I think the paragraph about cacheability should be removed, so that
> the general "not by default" rule applies from RFC 7231 Section 6.1.
> Or maybe even rewritten to say "Responses with the 421 status code
> MUST NOT be stored by a cache," as in RFC 6585.

I can't find any evidence of this being discussed explicitly (the wording was included in the original draft as adopted by the WG), although I do remember it coming up somewhere. 

I agree that with many use cases, having 421 be cacheable by default isn't very helpful, although it's easy enough to assure that it isn't cached (e.g., with Cache-Control: no-store). 

Does anyone else remember some more context around this?


> Should I report an erratum, or am I missing something?

Changing the cache semantics of an existing status code isn't an erratum, no matter how inconvenient. I think the best we could do would be to hold it for update, and even then the most we might be able to do would be to caution people to add CC: no-store in the common case.

Cheers,



--
Mark Nottingham   https://www.mnot.net/