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

On Wed, Jan 13, 2016 at 1:40 AM, Stefan Eissing <
stefan.eissing@greenbytes.de> wrote:

> > To summarize, the draft utilizes the fact that HTTP/2 multiplexes HTTP
> > requests into a single, ordered stream to make things simple.
> > Considering the fact that we need to rely on HTTP/2 to push things
> > anyways (that is the primary target of the draft), I think that is a
> > reasonable trade-off.
>
> There might be use cases to
> a) transport a cache digest over HTTP/1.1
> b) expose a cache digest to a web application
>
> I think the draft could define a header field for this purpose
> and describe its use. Specifically
> - HTTP/1.1 clients should make it a Connection header
> - HTTP/1.1 to H2 transformers may use it in calculating their
>   CACHE_DIGEST frames (depending on their caching strategy)
> - similar for H2 to HTTP/1.1 gateways
>
> So this header, let's call it "Cache-Digest" for the sake of
> discussion, could appear in HTTP/1.1 requests or on web server
> and clients internal APIs:
>
> ...
> Cache-Digest: <base64url encoded, golombset compressed digests>
> Connection: Cache-Digest
> ...
>
> The question is what a H2 origin server does with such a header,
> should it appear. Ignore, discard?
>
> I don't see that the draft should care about H2 header
> compression efficiency of such a beast. Sending it over H2
> seems more a curiosity to me.


Agreed. As was highlighted previously, exposing it via a header makes it
accessible to web developers (and removes the requirement for UA to support
this "natively" to get any benefit or use), which (to me, at least) far
outweighs the benefits of saving a few bytes.

ig