Re: Server Push and Caching

> On Aug 24, 2016, at 11:23 AM, Tom Bergan <tombergan@chromium.org> wrote:
> 
> On Wed, Aug 24, 2016 at 10:17 AM, Roy T. Fielding <fielding@gbiv.com <mailto:fielding@gbiv.com>> wrote:
> 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).
> 
> Out of curiosity, can you walk through how you arrived at that interpretation for this specific case? Are you essentially suggesting that the "push store" (or "side cache") should be treated more like a history list (RFC 7234, Section 6) rather than a true HTTP cache?

I mean that the hypermedia workspace (set of open windows, tabs, in-process memory, side cache, history, or whatever else you want to include in however you might want to implement a browser, which is completely unconstrained by HTTP) is not a cache at all -- it is part of the current rendering process of the browser. How you program that process to behave is entirely defined by you, not HTTP. Some people have written user agents that browse off-line CDROM content mapped into cache form as if it were a live website with stale backing content, regardless of how stale that content might be, because they were specifically designed for that purpose. Some users configure their browser in "never check" mode, because they prefer stale over "costs money".

It is not the responsibility of HTTP to define the process by which pushed responses are used; HTTP only defines how they are sent and what they mean upon receipt.

For the same reason, HTTP cache requirements provide rules for adhering to semantic transparency when it is desired. They do not require that every message store be a semantically transparent HTTP cache.

....Roy