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

[Kazuho Oku <[e-mail]>]

2016-01-18 18:02 GMT+09:00 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.

Thank you for the response.

Under the premise that we should be two attributes, one matches
against authority and one matches against path, I wonder if the former
should be named `domain`.

The positive side of naming it `domain` is that the name is the same
as that used with cookies.  The negative side is that the semantics
will not be the same as the cookies.

IMO we should have three types of authority-level scopes for a cache
digest: a) exact match of the authority (e.g. host:port), b) exact
match of the host, c) match against a wildcard certificate.  b) and c)
come from the definitions in RFC 7540 Section 10.1.  I also believe
that a) should be the default.

However, the three types do not map well against the Domain attribute
of Cookie.  Exact match only exists for b), and that is when the
Domain attribute is not used (however if we are to use make a) as the
default, we need to have the attribute defined in this case).

To summarize, even though the role is similar to the Domain attribute
of Cookie, we need to define totally different semantics for the
attribute for Cache Digest; and I am afraid re-using `Domain` might
cause confusion.


That said, I propose using the name `host`, with following semantics.

* if `host` attribute is not specified, the scope of the cache digest
is the authority
* if a non-wildcard `host` attribute is specified, the scope is the
host.  The value MUST be equal to the host part of the :authority
pseudo header
* if a wildcard `host` attribute is specified, the scope is the hosts
that match the wildcard.  The value MUST be equal to that provided by
the TLS certificate

-- 
Kazuho Oku