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

Kazuho,

thanks for your detailed feedback. I see that you have things in mind for cache digest that I had not understood. 

I would still argue for the standalone digest form and define a new parameter that specifies the digest type. For example:
   Cache-Digest: base64urldigest;type=fresh, base64digest;type=if-modified-since
with a default of "fresh".

To your other points, I agree.

> Am 21.01.2016 um 02:26 schrieb Kazuho Oku <kazuhooku@gmail.com>:
> 
> 2016-01-20 21:57 GMT+09:00 Stefan Eissing <stefan.eissing@greenbytes.de>:
>> I make another attempt, based on the feedback (Kazuho, please stop me if you prefer to work on this):
> 
> Sorry.  I thought I had responded to your email.  It has always been
> my pleasure (and fun) to discuss how we should design and implement
> cache digests.
> 
> I think we mostly agree on how the header should be designed.
> 
> Below, I will cover the semantic differences between yours and mine
> (laid out in https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0120.html),
> and my thoughts.
> 
>> Cache-Digest      = "Cache-Digest" ":" #digest-value
>> 
>> digest-value    = base64url-encoded-digest *( ";" digest-param )
> 
> I would like to have the encoded digest stored as a name-value pair,
> thereby allowing the client to store several types of digests within a
> single digest-value.
> 
> At the moment, the draft only covers how the digests of fresh
> resources in cache should be encoded.  However if all goes well, I
> anticipate that we would extend the spec., to support stale resources
> as well.  For such purpose, being able to store more than one type of
> digests in a single digest-value would make the header less redundant.
> 
> As an example, the header conveying a digest for fresh resources and a
> digest for stale resources with if-modified-since headers can look
> like:
> 
>  cache-digest: fresh=xxxxx; if-modified-since=yyyyy; authority=*.example.com
> 
> only in case if we use name-value pairs to encode the digest.
> 
>> 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.
> 
> I believe that a server should be able to determine the domain(s) the
> client considers the server to be authoritative for.
> 
> Therefore, I think that a) the default scope should be the value
> passed in by the `:authority` pseudo header, and b) otherwise the
> client should explicitly specify the scope using the language defined
> in RFC 6125 6.4.3.
> 
> Unless the scope is transferred over HTTP, HTTP servers need to have
> the knowledge of the common name in the TLS certificate being used.
> However that might not always be easy considering the fact that in
> some cases TLS terminators (run by a different entity) might be placed
> in front of the HTTP server, or in case we want to rolling-update
> certificates of a TLS terminator cluster from a host-level certificate
> to a wildcard certificate.
> 
> Requiring the client to always specify the scope of the digest aligns
> with the fact that in HTTP/1.1 and HTTP/2 specifications the Host
> header (or the :authority header) is transferred even if TLS
> certificate is used (and the fact that not the common name stored in
> the certificate but the value of the header IS used as the name of the
> authority).
> 
>> If the codec of a digest is unknown, the digest MUST be assumed
>> to be empty
> 
> If the codec of a digest is unknown, a server must behave as if it did
> not receive that digest.
> 
> Assuming it to be empty would mean that a server will consider the
> cache of the client to be empty.  It should mean to the server that
> the client's cache state is unknown (for the category of the resources
> (e.g. fresh)).
> 
> And this definition is important for extending the spec., to cover
> stale resources.  For example, if a client sends a digest of fresh
> resources and a digest of stale resources, a server knowing only how
> to handle the former should respect the former and ignore the latter.
> 
>> 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.
> 
> Agreed.
> 
>> 
>>> Am 18.01.2016 um 15:46 schrieb Kazuho Oku <kazuhooku@gmail.com>:
>>> 
>>> 2016-01-18 19:32 GMT+09:00 Julian Reschke <julian.reschke@gmx.de>:
>>>> 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
>>> 
>> 
> 
> 
> 
> -- 
> Kazuho Oku

Received on Thursday, 21 January 2016 11:09:13 UTC