Re: Clarification on HTTP caching (RFC 7234)

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?

On Tue, Apr 28, 2015 at 4:17 PM, 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?
>
> Will.
>
>
>
> On Tue, Apr 28, 2015 at 11:37 AM, Will Sargent <will.sargent@gmail.com>
> 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".
>>
>> 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.
>>
>
>