Re: Server Push and Caching

>  The only native HTTP mechanism for cache invalidation is described in RFC7234, Section 4.4:

I believe this is not entirely correct.  RFC7540 Section 8.2.1: 

   Server push is semantically equivalent to a server responding to a
   request; however, in this case, that request is also sent by the
   server, as a PUSH_PROMISE frame.

Meaning all well-specified semantics of an HTTP request are available to a Push Promise/client-initiated request.  

RFC7234 Section 5.2.1.4 defines one, (request cache-directive, no-cache):

   The “no-cache” request directive indicates that a cache MUST NOT use
   a stored response to satisfy the request without successful
   validation on the origin server.

It would be semantically incorrect to cancel a server-initiated request with a no-cache request directive for the sole reason that it is already has a cached response.  In fact, the premise that a server-initiated request with a no-cache request directive can already have a cached response violates semantic equivalency.  Any request, client or server initiated, with a no-cache request directive can not by RFC have a validated response in the cache.

Assuming the Push Promise goes through (client still may cancel the Push Promise for any reason), this clearly allows for overwriting an existing cached response, specifically replacing a cache entry.

I’m uncertain if there is a response that could complete a push promise in a way to remove a cache entry.  But by SPEC, it seems any server-initiated request (or client initiated request) with a no-cache request directive should invalidate the existing cache entry as soon as that request reaches the caching layer.  Arguably, replacement is a better use case anyways.

Related conversation: https://bugs.chromium.org/p/chromium/issues/detail?id=232040#c75 <https://bugs.chromium.org/p/chromium/issues/detail?id=232040#c75>

> I'm also not convinced that no-cache is the right way to signal invalidation. If the client receives a push promise with no-cache, I would interpret that to mean that all servers between the client and the origin (such as a CDN or reverse proxy between the client and the origin) have ensured that the pushed response is fresh from the origin server. This is what no-cache means: the response has been validated at the origin server. It does *not* mean that the client necessarily has an invalid version of the resource. What if the push promise has no-cache, and we take your idea to not cancel the push, but it turns out the client already has the most up-to-date version of the resource? We wasted time -- we could have canceled the push sooner. Better, IMO, to label the push promise with a conditional header describing the resource so the client can determine if the pushed response is more up-to-date than the resource it has cached. Also see this thread, which I forgot to link earlier:
https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0522.html <https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0522.html>

I assume you are referring to intermediaries (CDN/caching) sending push promises independently from the origin server?  From a technical point of view I completely agree with your assertion proxies MUST NOT send a push promise with a no-cache request directive unless they have validated the resource with the origin server.  However, this is the exact same model/flow as response no-cache directives, which is already implemented!  Namely, intermediaries should not replay push promises with a request no-cache directive without validating the cached response, just like it should not serve a cached response with a response no-cache directive without validating it.

> What if the push promise has no-cache, and we take your idea to not cancel the push, but it turns out the client already has the most up-to-date version of the resource? We wasted time -- we could have canceled the push sooner.  Better, IMO, to label the push promise with a conditional header describing the resource so the client can determine if the pushed response is more up-to-date than the resource it has cache.

This problem seems to be generic to the request/response model and cache directives, whether the request is initiated by the browser or by the server.  For example, if a client initiates a request with the no-cache cache directive, then it can be an equal waste of time if the cached response is already in fact valid.  I would hope that any solution to this problem would be generic and solve both cases.  Moreover, I believe existing work in progress (https://tools.ietf.org/html/draft-kazuho-h2-cache-digest-00 <https://tools.ietf.org/html/draft-kazuho-h2-cache-digest-00>) would solve this issue in a generic way AND be more efficient than canceling the push promise because with the proposal the push promise would not be sent in the first place!  



---
- David Witherspoon