- From: James M Snell <jasnell@gmail.com>
- Date: Tue, 6 Aug 2013 09:43:05 -0700
- To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
While I was, unfortunately, unable to get my http/2 client implementation ready in time for the berlin interop testing, I was able to take time over the last month to dig into the header compression implementation in greater detail and I would have to say that while I agree that the current design offers a great compression profile and is technically sound for what it offers, I am definitely -1 on adopting the currently defined scheme as is without making significant changes. There are a number of reasons for this position that I've talked about a few times already so I won't get into those again. For one, as my experimentation with the Stored Header Encoding and typed codecs demonstrates, it is possible to achieve good compression ratios using a much less complicated mechanism that is more "routing friendly", more streaming-based, has better support for ordered values (see Julian's recent comments on multi-valued header fields), has stronger memory consumption constraints and is easier to implement. Granted, we end up sending a few more bytes over the wire but that's OK, IMHO. Sending those few additional bytes is far better, in my opinion, than significantly increasing the implementation complexity of the protocol through seemingly endless premature optimization (repeat after me, "Perfect is the enemy of good"...) In my opinion, the differential encoding and the reference set both ought to go away; the more efficient typed codecs ought to be introduced; and the header table ought to be limited to 256 storage slots so that index positions never require more than a single octet to represent on the wire. We can keep incremental and substitution indexing... In other words, some variation of what I have proposed in http://tools.ietf.org/html/draft-snell-httpbis-bohe-11. Yes, I fully recognize that this approach ends up sending more bits over the wire on average, but that's ok. There are other approaches we can take (e.g. better sessions) that can address that gap. - James
Received on Tuesday, 6 August 2013 16:43:52 UTC