Re: Server Push and Caching

["Roy T. Fielding" <[e-mail]>]

> On Sep 6, 2016, at 8:42 PM, Mark Nottingham <[e-mail]> wrote:
> 
> 
>> On 25 Aug 2016, at 3:17 AM, Roy T. Fielding <[e-mail]> 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.

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