- From: Kazuho Oku <kazuhooku@gmail.com>
- Date: Fri, 8 Jan 2016 16:17:16 +0900
- To: ietf-http-wg@w3.org
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
Received on Friday, 8 January 2016 07:17:47 UTC