Re: Clarification on HTTP caching (RFC 7234)

> On 29 Apr 2015, at 9:17 am, Will Sargent <will.sargent@gmail.com> wrote:
> 
> So to clarify on the P.S: 
> 
> must-revalidate specifies the behavior as "cannot reach" in https://tools.ietf.org/html/rfc7234#section-5.2.2.1 but does not use the word "disconnect"
> 
> "In all circumstances a cache MUST obey the must-revalidate directive; in particular, if a cache cannot reach the origin server for any reason, it MUST generate a 504 (Gateway Timeout) response."
> 
> There's a reference to "disconnected" in https://tools.ietf.org/html/rfc7234#section-4.2.4 with similar language that seems to indicate that 5.2.2.1 is also a "disconnect"
> 
> 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).
> 
> "Likewise, a cache SHOULD generate a 112 warn-code (see Section 5.5.3) in stale responses if the cache is disconnected."
> 
> The confusion comes from https://tools.ietf.org/html/rfc7234#section-5.5.3 which says that 
> 
> "A cache SHOULD generate this if it is intentionally disconnected from the rest of the network for a period of time."
> 
> It's that "intentionally" that is confusing -- that seems to indicate that the cache has an "offline" mode that can be used when it does not want to revalidate results.  Also, what happens when a cache is unintentionally disconnected from the rest of the netework?
> 
> So, are these all talking about the same thing? 

Roughly. Many cache implementations go into a distinct state when the network isn't available, and the text you're reading is left over from the inclusion of the concept in previous versions of HTTP/1.1. We probably didn't do enough cleaning up around this text; Warnings didn't receive a lot of attention, because they're not widely implemented.

I've created a bug to track this for future revisions:
  https://github.com/httpwg/http11bis/issues/5

Cheers,



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

Received on Wednesday, 29 April 2015 00:16:36 UTC