Subject: Re: Server Push and Caching

From: Mark Nottingham <[email-masked]>
Date: Wed, 7 Sep 2016 13:42:17 +1000

> On 25 Aug 2016, at 3:17 AM, Roy T. Fielding <[email-masked]> wrote:
...
>> The cache can also store the response, but once the stream is closed, if that response is stale -- either because of the presence of one of the directives above, or some combination of `Expires`, `Age`, `Date`, and `Cache-Control`, it will need to be revalidated before use
...
> FWIW, the mistake above is in saying "response is stale … it will need to be revalidated".
> 
> An HTTP client is not required to revalidate a stale response.  It only needs to do so when
> ensuring semantic transparency, which is something that user agents frequently don't do
> within the scope of a single session (instead, they make requests based on configuration
> or on the state of their own request processing).

If you read the entire message, you would have seen:

>> Note that HTTP does not put constraints on _how_ the application uses that response after it comes through the API or the cache; it might use it multiple times (e.g., an image might occur more than once on a page, or more than one downstream client might have made the request). It's just that this reuse isn't in the context of a HTTP cache's operation.

You're correct that an HTTP *client* isn't required to revalidate a response, but a cache is. One of the problems I see in the definition of Server Push is that we tried to scope the reuse of a response by a client using terminology that's only relevant to the cache.

Cheers,

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

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 7 Sep 2016 10:22:54 -0700

> On Sep 6, 2016, at 8:42 PM, Mark Nottingham <[email-masked]> wrote:
> 
> 
> You're correct that an HTTP *client* isn't required to revalidate a response, but a cache is.

A cache isn't required to revalidate.  Only a client revalidates, and only
when it wants to do so.  A cache never makes requests.  A cache is only required
to mark the response as stale.  It is okay to have a cache that is 100% stale.

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 8 Sep 2016 10:06:35 +1000

> On 8 Sep 2016, at 3:22 AM, Roy T. Fielding <[email-masked]> wrote:

> to mark the response as stale.

From previous discussions, I know that's your view, and I think it's internally consistent. I'm less convinced that view is shared by implementations, or even the specs.

RFC 7234, Section 4: "A cache that does not have a clock available MUST NOT use stored responses without revalidating them upon every use."

Section 4.2.4: "A cache MUST NOT generate a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache directive, a "must-revalidate" cache-response-directive, or an applicable "s-maxage" or "proxy-revalidate" cache-response-directive; see Section 5.2.2)."

Section 4.3.2: "When a cache decides to revalidate its own stored responses for a request..."

Section 5.2.2.1: "The "must-revalidate" response directive indicates that once it has become stale, a cache MUST NOT use the response to satisfy subsequent requests without successful validation on the origin server."

Section 5.5.2:" A cache SHOULD generate this when sending a stale response because an attempt to validate the response failed, due to an inability to reach the server."

2616 contains much the same language.

Cheers,

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 11 Sep 2016 06:12:14 -0700

> On Sep 7, 2016, at 5:06 PM, Mark Nottingham <[email-masked]> wrote:
> 

Yes, that spec plays loose with the terminology.  Clients make requests.
In some cases, a cache contains a client. In other cases, a cache just
tells the calling client what it currently contains, and is updated as a
side-effect of whatever responses are received.

BTW, I haven't seen any evidence of that requirement enforced, at least for caches
that have an interval timer instead of a wall clock.  They just count the age.

> Section 4.2.4: "A cache MUST NOT generate a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache directive, a "must-revalidate" cache-r…

That's inconsistent -- it should be "MUST NOT use a stale response".  The reason
the spec has this requirement is because a cache MAY use a stale response
if it is not prohibited by those explicitly specific directives.

> Section 4.3.2: "When a cache decides to revalidate its own stored responses for a request..."

Should be "When a cache revalidates a stored response ..."

> Section 5.2.2.1: "The "must-revalidate" response directive indicates that once it has become stale, a cache MUST NOT use the response to satisfy subsequent requests without successful validation on…

That's fine.

> Section 5.5.2:" A cache SHOULD generate this when sending a stale response because an attempt to validate the response failed, due to an inability to reach the server."

Which wrongly assumes that a cache is a server (as does 4.2.4).

> 2616 contains much the same language.

Let's just agree not to go there.

> Cheers,

So, hold for document update?

I don't understand why this is even an argument.  RFC7234 claims that
it is specifying HTTP caching.  We know that caches appear inside all
forms of HTTP components (user agents, proxies, gateways, origin servers)
and in a variety of non-HTTP components (ISPs, captive portals, etc.).
We know that caches are often configured to be less than semantically
transparent.  We cannot seriously define "HTTP cache" to be only those
caches that limit stale reuse to those in section 4.2.4, as if the
components people call a "cache" in real life magically rename themselves
whenever they don't adhere to those requirements.

The reason I stick to my internally consistent views, instead of relying
on the RFC, is because the RFC is not currently capable of describing
how a user agent works with its own cache.  For example, see

  https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching

Likewise, semantic transparency isn't sufficient to encompass the configurations
of any performance-enhancing cache, like Squid and Apache TrafficServer.

I think we should just fix section 4.2.4 to not specify things in client/server
terms (rather, a cache adds to or removes from a stored response) and to allow
for cache behavior regarding stale responses to be based on context and
configuration.

Cheers,

....Roy