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

2016-01-15 14:24 GMT+09:00 Martin Thomson <martin.thomson@gmail.com>:
> 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.

Thank you for the suggestion.  That seems to be true.

Even though including hop-by-hop information as a HTTP header in
HTTP/2 seems strange, it will likely help people using cache digests.

> 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.

Agreed.

Regarding the issue, it is possible to include cache digest in every
HTTP request while maintaining the bandwidth spent for sending the
digests almost on par with when using an HTTP/2 frame, by using the
following approach.

A client should:
1) include entire cache-digest in the first HTTP request sent over an
H2 connection
2) for following HTTP requests, send two (or more) cache-digest
headers, one should contain the value sent in step 1), other(s) should
contain only the values that changed after step 1)

A server should merge the values of the cache-digest headers to
construct the client's cache digest.

In this approach cache-digest header containing all GCS keys (which is
likely to be large) are repeatedly sent, we can expect that it would
be efficiently compressed by HPACK (likely will become 1 byte or 2
byte).

The deltas associated to the following HTTP requests will be small and
can effectively ignored in terms of consumed bandwidth.

One downside of the approach is that the cost of decoding the header
might become an issue on the server-side; but server implementations
can cache the decoded values of the digest.

>> 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.

Agreed.

-- 
Kazuho Oku

2016-01-15 14:24 GMT+09:00 Martin Thomson <martin.thomson@gmail.com>:
> 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.



-- 
Kazuho Oku

Received on Friday, 15 January 2016 06:23:35 UTC