W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2016

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

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Fri, 15 Jan 2016 16:16:37 +0100
Cc: Kazuho Oku <kazuhooku@gmail.com>, Ilya Grigorik <ilya@igvita.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <32E2C157-5DFF-4AD8-86D5-2E2B422F4029@greenbytes.de>
To: Martin Thomson <martin.thomson@gmail.com>
I just released v1.2.0 of mod_http2 with support for
the 'Cache-Digest' request header 
(https://github.com/icing/mod_h2/releases/tag/v1.2.0)

When a request comes with

Cache-Digest: BAqbuEx20N-JQDERYEeacOaLNC6x_wA=

the value is assumed to be base64url encoded bytes of cache digest as
described in the draft. (The implementation may have some bits wrong, but
it works with itself at least...)

There is also a handler that can be configured in the server that hands
out JSON with some stats and the cache digest of the current connection.
I use this for my own testing, might come in handy to have that available
to client experimenters. How-to in the release notes.

-Stefan

> Am 15.01.2016 um 07:57 schrieb Martin Thomson <martin.thomson@gmail.com>:
> 
> On 15 January 2016 at 17:51, Kazuho Oku <kazuhooku@gmail.com> wrote:
>> Considering the fact that such APIs (that are incapable of expressing
>> states shared between the requests) exist, I think the semantics
>> should be defined in a way that every HTTP request can be complete by
>> itself if we are going to send cache digest as a header.
> 
> Yeah, I agree.  That doesn't preclude a mechanism that explicitly
> creates and references state, but that might be too complex to manage.
> Sending the whole table every time isn't great, but let's see if this
> is successful enough to warrant further optimization first.
> 
Received on Friday, 15 January 2016 15:17:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 22 March 2016 12:47:10 UTC