- From: Kazuho Oku <kazuhooku@gmail.com>
- Date: Mon, 18 Jan 2016 09:14:17 +0900
- To: Stefan Eissing <stefan.eissing@greenbytes.de>
- Cc: Martin Thomson <martin.thomson@gmail.com>, Ilya Grigorik <ilya@igvita.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
2016-01-16 0:16 GMT+09:00 Stefan Eissing <stefan.eissing@greenbytes.de>: > 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. Wow! Very fast! I'm delighted to hear that. > -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. >> > > -- Kazuho Oku
Received on Monday, 18 January 2016 00:14:46 UTC