Re: Clarification on HTTP caching (RFC 7234)

So to clarify on the P.S:

must-revalidate specifies the behavior as "cannot reach" in 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 with similar language
that seems to indicate that 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
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?


On Tue, Apr 28, 2015 at 11:37 AM, Will Sargent <>

> Hi all,
> I have some questions on the behavior of RFC 7234's s-maxage response
> directive -- it looks like the behavior for s-maxage response directive
> differs significantly from maxage in that a max-age response directive
> means that a stale response calls for "validate", where the behavior is
> "validate, but serve stale on a timeout or (if stale-if-error is defined)
> on a 5xx".
> Meanwhile, s-maxage says " The s-maxage directive also implies the
> semantics of the proxy-revalidate response directive."  Well,
> proxy-revalidate is the same as must-revalidate, but only operating on
> shared caches, and the validation behavior there is "validate or 503 on
> timeout".
> So the question is: the behavior of s-maxage explicitly to timeout rather
> than give a stale response?  I've been looking around the internets, and I
> don't see this behavior mentioned in the blogs or even in the O'Reilly Web
> Caching book or HTTP The Definitive Guide.
> Will.
> P.S.  I'm also confused as to what the difference between a "disconnect'
> and a "timeout" is -- in one area, a disconnect is referred to as "cannot
> reach the origin server" and in the warning it's referred to as
> "intentionally disconnected", but there's no direct reference to it.

Received on Tuesday, 28 April 2015 23:18:58 UTC