Subject: Clarification on HTTP caching (RFC 7234)

From: Will Sargent <[email-masked]>
Date: Tue, 28 Apr 2015 11:37:05 -0700

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.

---

From: Will Sargent <[email-masked]>
Date: Tue, 28 Apr 2015 16:17:50 -0700

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?

Will.

---

From: Will Sargent <[email-masked]>
Date: Tue, 28 Apr 2015 16:45:30 -0700

Follow up on the PS:

Warning 111 happens if a revalidation fails --
https://tools.ietf.org/html/rfc7234#section-5.5.2 but there is nothing in
RFC 7234 that refers back to Warning 111 (i.e. it doesn't show up in
section 4.2.4, which skips from 110 to 112).

So the way I'm reading it right now --  if a revalidation occurs (resulting
in a conditional GET request) and the origin server cannot be found, but a
stale response is there:

* 110 should be sent, because it's a a stale response.
* 111 should be sent, because revalidation failed.
* 112 should be sent, because the cache is disconnected.

Then, there's stale-on-error --
https://tools.ietf.org/html/rfc5861#section-4.1 shows an example which
doesn't show any warnings, although 4.2.4 says it should at least be
sending back a 110.   Is this correct?

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 29 Apr 2015 10:16:06 +1000

Hi Will,

> On 29 Apr 2015, at 4:37 am, Will Sargent <[email-masked]> wrote:
> 
> 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".

Yes.

> 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".

Yes. 
> 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.

Yes - see <http://httpwg.github.io/specs/rfc7234.html#serving.stale.responses>

> 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.

Following up separately.

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

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 29 Apr 2015 10:16:10 +1000

> On 29 Apr 2015, at 9:17 am, Will Sargent <[email-masked]> wrote:
> 
> 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?
> 

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,