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

[Stefan Eissing <[e-mail]>]

I make another attempt, based on the feedback (Kazuho, please stop me if you prefer to work on this):

Cache-Digest      = "Cache-Digest" ":" #digest-value

digest-value    = base64url-encoded-digest *( ";" digest-param )
digest-param    = name "=" value
name            = token
value           = token | quoted-string

base64url-encoded-digest is the binary output of the cache digest codec, 
encoded as a base64url string (that is, the URL- and filename-safe 
Base64 encoding described in Section 5 of [RFC4648], with any trailing 
'=' characters omitted). 

The following digest parameter are defined:
"domain"   value is authority, as defined in RFC3986, or 
          wildcard-identifiers, as defined in RFC 6125 6.4.3. 
          The implicit default for the domain value is "*".
"path"     value is a path-absolute, as defined in RFC3986 3.3.
          The implicit default for the path value is "/".
"codec"    the identifier of the algorithm used to calculate
          the cache digest.
          The implicit default for codec is "GCS-SHA256".

Digest from a Cache-Digest header always replace any matching 
existing digests. Multiple digests in one request are additive. This
allows additions to earlier digests in a form, which can be 
beneficial when using HTTP/2 header compression.

A digest replaces any existing digest if its domain parameter
matches the domain of an existing digest (with '*' matching any
domain) and the path parameter is a prefix of or equal to the
existing path.

If the codec of a digest is unknown, the digest MUST be assumed
to be empty and SHOULD replace any matching existing digests.

A candidate of a server push is matched against a cache digest
by comparing its :authority against the digest domain (port number?)
and its :path against the digest path (equal or prefix). Only
then is the candidate matched against the digest content.

> Am 18.01.2016 um 15:46 schrieb Kazuho Oku <[e-mail]>:
> 
> 2016-01-18 19:32 GMT+09:00 Julian Reschke <[e-mail]>:
>> On 2016-01-18 11:19, Stefan Eissing wrote:
>>> 
>>> +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 ) )
>>> ...
>> 
>> 
>> I wouldn't use angle brackets here; let's leave them for use in places where
>> the value is a URI (Link header field and several WebDAV header fields).
>> 
>> Just us token/quoted-sting here.
>> 
>> Also, do not wire parameter names into the ABNF; this mixes syntax with
>> semantics.
> 
> Thank you for the advice.
> 
> Obviously I have used an old-fashioned RFC as a reference when writing
> the ABNF (that Stefan probably modified).  I should have looked into a
> newer one, such as the Alt-Svc draft.
> 
>> Best regards, Julian
> 
> 
> 
> -- 
> Kazuho Oku
>