Re: Submitted new I-D: Cache Digests for HTTP/2

[Amos Jeffries <[e-mail]>]

On 3/02/2016 7:09 a.m., Richard Bradbury wrote:
> On 27/01/2016 04:38, Kazuho Oku wrote:
>> 2016-01-23 2:47 GMT+09:00 Richard Bradbury:
>>> ... This would allow a server to push a more
>>> up-to-date version of a representation in the case where that
>>> representation
>>> has been updated before the originally stated expiry. This allows a
>>> server
>>> to supply the freshest possible version, overriding the client's (in
>>> this
>>> case mistaken) belief that its cached copy is still fresh.
>>>
>>> You suggest below that a client would ignore such a push because it
>>> still
>>> believes its copy to be fresh, thereby defeating the server's attempt to
>>> push a fresher version.
>> Actually I had thought the same.
>>
>> However, my current understanding is that Firefox behaves like that
>> (i.e. ignore the pushed resources if a fresh entry already existed in
>> cache), and from what I heard such behavior conforms to the HTTP/2
>> specification.
> 
> I just re-read [RFC 7540 Section 8.2] and couldn't find any text
> explaining how a client should deal with pushed responses that are
> fresher than a cached item that is still believed to be fresh. The main
> requirement is that the promised request is cacheable, as defined by
> [RFC 7321 Section 4.2.3], and the specification then goes on to say that
> pushed responses can be cached by the client if it implements a cache.
> And that's about it as far as I can work out.

That is because PUSH by itself cannot do conditional requests. Consider
it to be the equivalent for a non-conditional request that always gets
the 200 status response with full new object and new expiry details.


The C-D information is needed from the client for the server to estimate
whether a conditional would have been used and a 30x status PUSHed.

> 
> The implementation in Firefox you describe sounds like a reasonable,
> simple strategy for dealing with HTTP/2 server push that suits a limited
> set of common web browsing Use Cases. Yes, the implementation conforms
> to the HTTP/2 specification, but only because the specification is
> silent on what to do in the more advanced scenario I have introduced.
> 
> Pragmatically speaking, if a user agent is not willing to accept a
> pushed representation that is fresher than something it (incorrectly)
> believes to be still fresh, then your proposed "if-modified-since"
> conditional request is the next best way of getting fresher items into
> the client's cache. Because it relies on the client taking the
> initiative (to find out what is stale and what is still fresh) it does
> feel suboptimal, which rankles a bit. But, having bounced the idea
> around with you, it could be that a client-initiated mechanism is the
> best that can be achieved short of first clarifying the rules for
> caching pushed responses in the HTTP/2 specification, and then
> persuading browser developers to implement those rules.


Objects can be updated earlier than expected in normal HTTP proceedings.
That does not mean the client belief about freshness is wrong/incorrect.
The original object came with cacheability stating it was fresh for some
time period N. It just means there is a fresher copy that could also be
used for more accurate rendering if (and only if) the client happened to
request an update before that N period ran out.

Advertising, tag clouds, suggested linksets, etc. do this type of lazy
refresh routinely. Content could be a lot more dynamic than any one
client sees without raising bandwidth for the service as a whole.

Amos