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

[Martin Thomson <[e-mail]>]

I think that this would be a little less tortured if you accept that a
Cache-Digest header field is the primary or only source of truth.

The frame might then be dropped entirely, apart from one concern, below...


On 15 January 2016 at 14:49, Kazuho Oku <[e-mail]> wrote:
> We might still want to define how a digest value can be unset from the
> server-maintained digest; one way will be to use a flag to indicate
> whether if the CACHE_DIGEST frame is a delta to the previous or if is
> a replace.  Or clients can simply close the H2 connection to clear the
> server-side digest.

The advantage that a frame provides is that it can be assumed to have
state shared between requests.  A header field cannot assume the same.
Therein lies the problem.

> It should also be noted that IIRC SW cannot be defined for an entire
> domain.

A SW can speak for an entire origin (scheme+host+port), but I wouldn't
recommend it since it makes other operational aspects of SW more
challenging.  If you like, an optional parameter could be added to a
header field to describe the "scope" that the Cache-Digest covers.