W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

Header Compression...

From: James M Snell <jasnell@gmail.com>
Date: Tue, 6 Aug 2013 09:43:05 -0700
Message-ID: <CABP7RbeA1GXFonn7JdnZJzSCr5WAikMrdNNNoS07nqPXrrBRNA@mail.gmail.com>
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

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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC