- From: Kazuho Oku <kazuhooku@gmail.com>
- Date: Mon, 18 Jan 2016 09:18:49 +0900
- To: HTTP Working Group <ietf-http-wg@w3.org>
FWIW, I have implemented a simulator of the I-D, which is now available at https://github.com/kazuho/h2-cache-digest. When running `make`, it generates a command named `h2-cache-digest-00`, which can be used as a simulator for the draft version 00. It accepts three mode: `--encode`, `--decode`, `--push`; each mode can be used for encoding / decoding the frame as well as a simulator on the server-side checking where if a URL should be push (or not be pushed in case the resource is expected to be cached by the client). A synopsis of how to use the command can be found on https://github.com/kazuho/h2-cache-digest#h2-cache-digest-00 I hope this will help people understand how the draft can be implemented. Thank you in advance. 2016-01-08 16:17 GMT+09:00 Kazuho Oku <kazuhooku@gmail.com>: > Hello, > > Yesterday, Mark and I have submitted a new draft named "Cache Digests > for HTTP/2." > https://datatracker.ietf.org/doc/draft-kazuho-h2-cache-digest/ > > The draft proposes a new HTTP/2 frame named CACHE_DIGEST that conveys > client's cache state so that a server can determine what should be > pushed to the client. > > Quoting from the introduction of the I-D: > HTTP/2 allows a server to "push" synthetic request/response pairs > into a client's cache optimistically. While there is strong interest > in using this facility to improve perceived Web browsing performance, > it is sometimes counterproductive because the client might already > have cached the "pushed" response. > > My estimation is that in some cases a server may be able to push > hundreds of kilobytes of asset files critical to the rendering path > (e.g. CSS and script files) before the main content (i.e. HTML) is > returned from the application server, and having such fingerprint is > essential for determining what to push (for better > perceived-performance) and for determining what not to push (to not > waste the bandwidth). > > A more detailed explanation of how it works can be found in the link > below, which describes the test I conducted using H2O HTTP/2 server's > cache-aware server-push feature (this I-D is essentially an effort to > standardize the feature). > http://blog.kazuhooku.com/2015/12/optimizing-performance-of-multi-tiered.html > > You may be also interested in the following slides explaining how the > feature is implemented in H2O version 1.5. > http://www.slideshare.net/kazuho/cache-awareserverpush-in-h2o-version-15 > > Source code of the Golomb-Rice encoder used in the cache-aware > server-push of H2O can be found at: > https://github.com/kazuho/golombset/ (note: it encodes "N" and "P" > differently from the steps defined in the I-D since in the H2O's > implementation the server is capable of maintaining "N" out-of-band). > > Please let us know how you think about the proposal. Thank you in advance. > > -- > Kazuho Oku -- Kazuho Oku
Received on Monday, 18 January 2016 00:19:18 UTC