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

[Kazuho Oku <[e-mail]>]

2016-01-14 23:13 GMT+09:00 Ilya Grigorik <[e-mail]>:
> 
> On Thu, Jan 14, 2016 at 12:55 AM, Kazuho Oku <[e-mail]> wrote:
>> 
>> So a SW trying to send cache digest needs to send the value without
>> designating it as a hop-by-hop header.  And that means that if a H2
>> origin server sees the header, it needs to determine if the request
>> came through an intermediary, and only use the value if it did not.
>> Or else, a server might end up repeatedly pushing resources to a
>> caching proxy that already has them cached.
>> 
>> This looks like a hack to me, and I am not sure if it should be
>> permitted within a specification, even though I believe it would work
>> effectively (as we are doing in H2O).
> 
> 
> With HTTPS in place, I think you can make some reasonable simplifying
> assumptions here.. that'll make things work in practice.

Agreed.

I still think this is very tricky, but we could possibly define
Cache-Digest header as a hop-by-hop header that would be capable of
representing the contents and flags of a CACHE_DIGEST frame, and state
that:

* the header SHOULD NOT be sent over an HTTP/2 connection
* a gateway MAY use the header to transfer the cache-digest value of a
client to upstream
* a client incapable of creating HTTP/2 frames (e.g. XMLHttpRequest,
Fetch API) MAY use the header in place of the CACHE_DIGEST frame; if
and only if it is estimated that the underlying connection will
directly connect to the origin server (ie. HTTPS)
* a server MAY handle the value of the header as if it was an HTTP/2 frame

Besides, we should alter how a server should behave when seeing the
digest more than once, considering the fact that HTTP/1 APIs do not
generally have the guarantee that the requests will be sent in the
order the API was called.  When receiving a new cache digest, a server
should merge the value with the value already in possession, instead
of replacing the old value with the new one.

This change will actually help the case in which multiple H2
connections are established between the client and the server; since
by changing the meaning of following CACHE_DIGESTs from replace to
merge, it becomes possible to update the cache digest maintained on
the server side by only sending the delta of the changes that happened
on the client side.

We might still want to define how a digest value can be unset from the
server-maintained digest; one way will be to use a flag to indicate
whether if the CACHE_DIGEST frame is a delta to the previous or if is
a replace.  Or clients can simply close the H2 connection to clear the
server-side digest.



Also, we may need to consider how CACHE_DIGEST-aware web browsers
should communicate with SW.

Considering the fact that SW is essentially a proxy implemented within
the browser, I believe CACHE_DIGEST-aware web browsers should include
within the request it passes to SW the digest of the browsers' cache
using `Cache-Digest` header.

SW may alter the value, and then issue an HTTP request with the
`Cache-Digest` header using Fetch API.

The Fetch API implementation of the web browser should convert the
value supplied in the `Cache-Digest` header to a HTTP/2 frame before
sending the request over the network.  It should also try to minimize
the size of the frame, by calculating the difference between the
supplied digest value and the previously-sent values, and only send
the difference as the delta (as discussed in the above issue).

Or else, there should be an interface for reading / writing cache-digest values.

It should also be noted that IIRC SW cannot be defined for an entire
domain.  That means that in case SW is registered (and if SW is
capable of altering the cache-digest), a client MUST NOT try to send
cache digest for the entire domain even when other conditions permit
(i.e. server sends an wild-card certificate).

> ig



-- 
Kazuho Oku