W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2016

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

From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 15 Jan 2016 16:24:43 +1100
Message-ID: <CABkgnnVdR0fi9QKHT=tZUzAzAYe+XxG-oEj=srZGX0TMEkHcuw@mail.gmail.com>
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: Ilya Grigorik <ilya@igvita.com>, Stefan Eissing <stefan.eissing@greenbytes.de>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
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 <kazuhooku@gmail.com> 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.
Received on Friday, 15 January 2016 05:25:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 22 March 2016 12:47:10 UTC