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

[Kazuho Oku <[e-mail]>]

Under the premise that we are switching to using an HTTP header, my
idea at the moment is to define it like:

  cache-diges = 1#cache-digest-element
  cache-digest-element = cache-digest-nv *(OWS ";" OWS cache-digest-nv)
  cache-digest-nv = fresh-nv / authority-nv

  fresh-nv = "fresh=" fresh-value
  fresh-value = BASE64 encoded GCS defined in h2-cache-digest-00
(without padding)

  authority-nv = "authority=" authority-value
  authority-value =
        authority              # defined in RFC3986
        / wildcard-identifier  # defined in RFC 6125 6.4.3

IMO the definition covers most of the requirements of / suggestions
provided by many, including the 4 points described below:

1. Cache-Digest can be expressed as a header

For example, a Cache-Digest containing https://example.com/style.jss
and https://example.com/jquery.js will look like:

  cache-digest: fresh=AQiZAh8


2. Effective compression with HPACK

A client can make the use of HPACK to effectively compress the
cache-digest that changes slightly per every HTTP request, by
splitting a cache-digest to two headers: a large header that does not
change per every request, and a small header that encodes the delta
from the large header.

For example, a client sends a large cache-digest header in the first
HTTP request after establishing an HTTP/2 connection.

  cache-digest: fresh=ABC...xyz      # very large header

In the following HTTP requests sent over the same connection, a client
will resend the header sent in the first connection, plus a second
header containing the delta from the first connection.

  cache-digest: fresh=ABC...xyz      # the same header as above
  cache-digest: fresh=ax9e           # digest containing delta from above


3. Specifying the scope

In case the server is known to be authoritative for the entire domain
(e.g. wildcard certificate is used), a client can send a cache-digest
for all the hosts under that domain, by specifying the `authority`
attribute.

  cache-digest: fresh=xxxxx; authority=*.example.com


4. Possibility to extend the header

There has been discussions if we should support an encoding other than
GCS, or how we can send cache-digests of a non-fresh resource.

The ABNF has a room to support digests other than just the `fresh`
digest (that represents the fresh resources within the cache using
GCS); for example, we can afterwards define an attribute named
`fresh-bf` for representing a digest of fresh resources using bloom
filter

  cache-digest: fresh-bf=...

or, we can define an attribute named `if-modified-since` to represent
a digest of non-fresh resources, once we agree how they should be
hashed.

  cache-digest: if-modified-since=...


2016-01-15 15:57 GMT+09:00 Martin Thomson <[e-mail]>:
> On 15 January 2016 at 17:51, Kazuho Oku <[e-mail]> wrote:
>> Considering the fact that such APIs (that are incapable of expressing
>> states shared between the requests) exist, I think the semantics
>> should be defined in a way that every HTTP request can be complete by
>> itself if we are going to send cache digest as a header.
>
> Yeah, I agree.  That doesn't preclude a mechanism that explicitly
> creates and references state, but that might be too complex to manage.
> Sending the whole table every time isn't great, but let's see if this
> is successful enough to warrant further optimization first.



-- 
Kazuho Oku