Re: Server Push and Caching

[Mark Nottingham <[e-mail]>]

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