Re: Server Push and Caching

On 27/05/17 09:50, David Witherspoon wrote:
> Yes, thanks for the clarification.  I agree invalidation is too strong 
> of wording.  Rather a request with cache-control: no-cache directive 
> allows for updating or adding entries to the cache.
>
> > it certainly doesn't MUST or even SHOULD it.
>
> I believe I might still disagree but let me clarify the scenario:
>
> 1. client issues request 1, and gets a cache-able response 1.
> 2. The client then issues the same request (request 2) but with the 
> no-cache cache request directive and gets a cache-able response 2 from 
> the origin server.
> 3.  The client issues request 3 that matches both previous requests 
> and assume both responses are valid.  rfc7234#section-4.4 states that 
> "When more than one suitable response is stored, a cache MUST use the 
> most recent response".  So response 2 would presumably be served from 
> cache to answer request 3  (OR It can also forward the request with 
> "Cache-Control: max-age=0" or "Cache-Control: no-cache" to 
> disambiguate which response to use.)
>
> If we now assume that request 2 is server-initiated via a push 
> promise, and that the push promise is not cancelled, and the client 
> "is just replaying" it onto the cache then I would assume Step 3 MUST 
> operate in the same way.

After that step-2 has occured there are only one of two situations possible:
* the cache ignored the response-2 and contains the response-1, or
* it replaced/updated the cache contents with response-2.

The Cache-Control header is exceptionally unlikely to be part of the 
Vary header list, so it is almost not possible to emit a single 
request-3 that causes the response-1 and response-2 to be treated as 
different representations of the same resource. It is possible they are 
different in some other way, but that no-cache itself is irrelevant to 
the variation identity.


>
> > I do agree that a cached-response that you wouldn't use to satisfy 
> the pushed request is not a good rationale for canceling the pushed stream
>
> Agreed, this arose because Chrome has a PR that implements an 
> optimization on their implementation of just replaying it onto the 
> cache.  That optimization "Cancel[s] unnecessary push streams when 
> it's discovered they're in cache".  I believe the semantics of a 
> no-cache request header is well defined such that it can't already be 
> discovered in cache.  Sure it can cancel the Push Promise for any 
> reason, but in this case, it is ignoring the semantics that the 
> no-cache request directive syntax defines.

The semantics of request CC:no-cache is that a cache *MAY* be updated. 
There is no requirement that the updates be stored for future clients.

PUSH simply proactively delivers a response that can be sent on as-is to 
the client, skipping delivery of whatever the cache contained.

If the cache decides to cancel a PUSH stream with no-cache or any 
similar revalidation requirement, the only thing it affects is to 
prevent itself from being able to PUSH that resource onwards. Middleware 
caches must wait to see if the client really does send that requirement 
and handle it in the normal way for such requests. Browser / UA caches I 
would expect to have better info on hand than a remote server - so that 
information should be informing the decision to cancel the push.


>
> Note, if response 2 has a longer validation lifetime then response 1, 
> then I believe it is behaviorally equivalent to invalidating response 1.

Only if the PUSH'd response is cached instead of cancelled. If it got 
cancelled there is no complete response object to do cache replacement with.


Amos

Received on Saturday, 27 May 2017 03:01:29 UTC