Subject: Cacheability of 421 (Misdirected Request)

From: Vasiliy Faronov <[email-masked]>
Date: Mon, 11 Apr 2016 04:19:56 +0000

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.

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

-- 
Vasiliy

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 14 Apr 2016 12:37:19 +1000

Hi,

> On 11 Apr 2016, at 2:19 PM, Vasiliy Faronov <[email-masked]> wrote:
> 
> Hi,
> 

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/

---

From: Glen Knowles <[email-masked]>
Date: Thu, 14 Apr 2016 11:30:03 -0700

On Wed, Apr 13, 2016 at 7:37 PM, Mark Nottingham <[email-masked]> wrote:

>
> 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).
>
If no where else, it was discussed briefly as part of this thread:
https://lists.w3.org/Archives/Public/ietf-http-wg/2015AprJun/0480.html