Re: Server Push and Caching

On Wed, May 24, 2017 at 1:27 PM, David Witherspoon <
dwitherspoon2011@gmail.com> wrote:

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

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

istm that you are confusing invalidation with use. 5.2.1.4 doesn't say
anything about invalidating the cache - bypassing when satisfying that
request is fine and even sensible if you expect multiple variants. Sec 4.4.
does talk about invalidation in the face of responses to unsafe methods but
a] 7540 does not allow pushing unsafe methods, and b] 4.4. is clear that
this only applies to caches that it "travels through" and its not clear
that 7540 push operates directly on a cache even though it has cache
semantics.

its not clear exactly how pushes should be applied by clients.. they are
making small movements towards "just replaying them" onto the cache
directly, but its obvious that can't be the whole story.. e.g. a response
containing cache-control: no-store is explicitly allowed for use by 8.2 and
that wouldn't work if promised streams were just directly use to populate a
cache.


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

I don't know that I would go as far as "semantically incorrect" because I
don't think you have the semantics you're looking for :).. but 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. But as far as
correctness goes, you don't need a good reason to correctly cancel any push.


> 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.
>
>
I would agree with that. but I think you might also be implying that the
cache needs to invalidate any previously stored entry for the same URL..
and I don't agree with that :) (though it could.)



> 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 agree it allows that. it certainly doesn't MUST or even SHOULD it. It
might be reasonable.