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

>
>
>
> Considering the fact that H2 push is optional (and Cache Digests for
> HTTP/2 is an option to H2 push), I am afraid it might not become the
> standard way to update a fresh response.
>
> If we are to solve cache busting, it might be better to consider
> adding a validator to the link-rel-preload header. For example, we
> could add a etag attribute, that presents the etag value that is
> _expected_ to be used together with the response that contained the
> link header. Upon observing such header, clients can check their
> cache, and in case the validators do not match, remove the response
> from cache and issue a new request.
>
> In other words,
>
>   link: </style.css>; rel=preload; etag=deadbeef
>
> would instruct the web browser to fetch /style.css if it is not
> fresh-cached, or if the etag value of the cached response does not
> match the value supplied by the header.
>

This is a good mechanism! It may require a bit of common sense to avoid
race conditions between PUSH_PROMISEs and STREAM_RESETs but that's not too
much to ask. And as you said, it can even be used with HTTP/1.1

I have opened a ticket in the preload draft and added your text above:
https://github.com/w3c/preload/issues/68 ...


> The pros of this approach would be that it could be used over both
> HTTP/1 and HTTP/2, and that it does not require the browser to
> implement H2 push. The cons would be that it would only be possible to
> invalidate responses as part of the preload process.
>
> >>
> >>
> >> >>
> >> >>
> >> >> 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.
>
> Thank you for the clarification.
>
> > ./Alcides.
> >
>
>
>
> --
> Kazuho Oku
>