Re: Call for Adoption: Cache Digests for HTTP/2

Hi all,

The draft currently has 4 supporters (6 including the authors) and 1 reference to experiment (not sure if this counts as implementation). Please let the list know if you have any strong opinions for / for not adopting the draft. Also let the list know if you have interest in implementing the draft.

Thanks!

Natasha


Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | nrooney@gsma.com<mailto:nrooney@gsma.com> | +44 (0) 7730 219 765 | @thisNatasha | Skype: nrooney@gsm.org<mailto:nrooney@gsm.org>


On Jun 23, 2016, at 4:33 PM, Alcides Viamontes E <alcidesv@zunzun.se<mailto:alcidesv@zunzun.se>> wrote:


Hello Kazuho,

Thanks! Comments below.

On Wed, Jun 22, 2016 at 11:29 PM, Kazuho Oku <kazuhooku@gmail.com<mailto:kazuhooku@gmail.com>> wrote:
Hello,

Thank you for your insights. I am eager to see your experiment results
once it gets ready.

2016-06-22 20:39 GMT+09:00 Alcides Viamontes E <alcidesv@zunzun.se<mailto:alcidesv@zunzun.se>>:
> Hello Cory,
>
> It's good to have your feedback. Below are answers to your comments, but I
> do expect to use this conversation to fill my gaps.
>
> On Wed, Jun 22, 2016 at 12:43 PM, Cory Benfield <cory@lukasa.co.uk<mailto:cory@lukasa.co.uk>> wrote:
>>
>>
>> > On 22 Jun 2016, at 09:28, Alcides Viamontes E <alcidesv@zunzun.se<mailto:alcidesv@zunzun.se>>
>> > wrote:
>> >
>> > This is bad for several reasons. AFAIK, sites don't have either a way to
>> > ask the browser to prematurely evict an expired representation that the
>> > browser would otherwise consider fresh. These two things together could
>> > allow a cache digest to grow indefinitely. Wouldn't that have a degrading
>> > effect on performance?
>>
>> This is presumably true of caching to begin with, correct? If the browser
>> doesn’t consider the cached representation stale it is welcome to not emit a
>> request for it at all, and simply to serve it from its cache. This means
>> that the cache digest can only grow as large as the client cache allows it
>> to grow, which I should certainly hope is not indefinitely large!
>
>
> Yes, this is related to caching in general. And it is the reason people have
> to add query strings for doing cache busting. This problem is a separate
> issue, but it interacts with cache digests in that old version of assets are
> kept in the cache and  therefore in the cache digest and the origin have no
> way of removing it. The origin can only create a new URL (say, via a new
> query string) that gets added to the cache and the cache digest.

I share your concern (though I might disagree on how critical the issue is).

Actually, the draft provides a way to update fresh responses _if_ the
client and server agree.

In the current version of the draft, we have intentionally defined
VALIDATOR and STALE as separate flags, to allow a client to send a
digest of fresh resources with their validators taken into account. A
server can use such digest (i.e. a digest with VALIDATOR flag set and
STALE flag not set) for pushing an updated version of the resource.

So if the client is to accept push of a fresh response to replace an
already-existing fresh resource (the HTTP/2 spec. does not specify if
it should or not), the mechanism can be used, and in such case, cache
busting would no longer be necessary.

That's really good news! What can be done to make this mechanism less a matter of browser goodwill?


>>
>>
>> However, it may be sensible to consider providing a SETTINGS field that
>> allows servers to flag a maximum size on a cache digest that it is willing
>> to accept.
>
>
> But this leaves the server without any control about which things are made
> part of the cache digest. That's why we think scoping and an explicit
> eviction mechanism are better long term solutions.

We could extend the current draft if scoping would be an issue, and it
would be possible to do so with keeping backward compatibility. For
example, we could add a new flag that indicates that the scope of the
digest is limited to certain mime-type and that the mime-type is
stored in the frame in addition to the digest-value.

That said, does your concern about the size of the digest dissolve
without adding a method for a server to notify the client the maximum
permitted size of the digest (e.g. a SETTINGS field as suggested by
Cory)?

After some reflection, I must agree that limiting the size of the digest is probably a good compromise until we know if scopes are really needed. This setting could even be used to make the digests opt-in, which is a plus.

./Alcides.



This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call +44 207 356 0600 and highlight the error.