Re: Server Push and Caching

[David Witherspoon <[e-mail]>]

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.

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

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

On Fri, May 26, 2017 at 1:16 PM, Patrick McManus <[e-mail]>
wrote:

>
>
> On Wed, May 24, 2017 at 1:27 PM, David Witherspoon <
> [e-mail]> 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.
>
>
>