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

[Stefan Eissing <[e-mail]>]

+1 generic header parameter form.

If I may make a proposal:

Cache-Digest      = "Cache-Digest" ":" #digest-value
  digest-value    = "<" base64url encoded digest ">" *( ";" digest-param )
  digest-param    = ( ( "domain" "=" domain-value )
                  | ( "path" "=" path-value )
                  | ( "codec" "=" codec-value )
                  | ( "update" ( "=" update-param ) )
                  | ( digest-extension ) )
 
 digest-extension = ( parmname [ "=" ( ptoken | quoted-string ) ] )

 domain-value     =
       authority              # defined in RFC3986
       | wildcard-identifier  # defined in RFC 6125 6.4.3

 path-value       = path-absolute    # defined in RFC3986 3.3

 codec            = ( "GCS-SHA256" | ( ptoken | quoted-string ) )

An endpoint seeing a cache-digest for an unknown codec should ignore the header. "GCS-SHA256" is the default codec, as described in...

"update" should indicate that the digest is intended as an update to (as opposed to replace) any cache information that an endpoint might already have. How delta digests are updated depends on the codec used. GCS-SHA256 defines only additions of new values.

If more than one Cache-Digest header is defined, header values are merged as defined for generic header parameter form, e.g. concatenation with "," as separator. When interpreting multiple digests, order is relevant in regard to "update" semantics.

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

 :authority/Host: example.com
 cache-digest: <AQiZAh8>

or, explicitly mentioning defaults:

 cache-digest: <AQiZAh8>;codec=GCS-SHA256;domain="example.com";path="/"

which, again, is equivalent to 

 cache-digest: <AQiZAh8>;codec="GCS-SHA256";domain=example.com;path=/


I am not keen on the exact names and wordings here...

As to "domain" and "path", I can certainly understand the need for "domain". How exactly "path" should/needs to be honored by an endpoint, is not clear to me. I tend to lean in the direction to ignoring "path" in my implementation. Is that safe with what usage you have in mind with this?

-Stefan

> Am 18.01.2016 um 10:02 schrieb Martin Thomson <[e-mail]>:
> 
> On 18 January 2016 at 18:41, Kazuho Oku <[e-mail]> wrote:
>> Should we define `path` attribute for the purpose?
> 
> Maybe.  SW calls it scope, which makes it tricky to map out.  Perhaps
> renaming the other from scope to domain would be better.