- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Fri, 4 Nov 2016 11:07:44 +1100
- To: Patrick McManus <mcmanus@ducksong.com>
- Cc: Jyrki Alakuijala <jyrki@google.com>, Vlad Krasnov <vlad@cloudflare.com>, Matthew Kerwin <matthew@kerwin.net.au>, HTTP Working Group <ietf-http-wg@w3.org>
On 4 November 2016 at 01:45, Patrick McManus <mcmanus@ducksong.com> wrote: > We should also be congnizant of the recent movement towards > "content-encodings should be self describing" that came out of the encrypted > object draft discussion - which sdch doesn't quite match (yet?). Perhaps a > brotli with a uri for its custom dictionary combined with push of the dict > gets us there (handwave). I think that the main innovation in Vlad's proposal is that he doesn't necessarily rely on a separate dictionary resource, he uses real resources to prime the dictionary. That means that you never spend bytes on stuff that isn't immediately useful to you. I'd be very interested in seeing what effect that has on things like responsiveness. I agree with you that the content encoding being self-descriptive is valuable, but I'm not quite seeing how we can get both of these things just yet. Maybe URLs are the wrong answer and we simply need to identify a shared context somehow. If you take Jyrki's observation that you might want multiple dictionaries, you can have a header that includes a list of dictionaries you want to use, plus optionally the dictionary that you want to append to with this response. Spitballing here... would identifying the context with a hash of its state work? Using hashes means that you don't ever have a problem with state synchronization. Synchronization is very much a problem if you move to something like QUIC where inter-stream ordering is loose, and it acts as a sanity check that you aren't corrupting data.
Received on Friday, 4 November 2016 00:08:17 UTC