Re: Header Compression Implementation Feedback

[James M Snell <[e-mail]>]

Another minor item as I've been going through the implementation:

4. Right now, the Header Compression scheme assumes two separate
pre-filled header tables... one for Request headers, the other for
response headers. The challenge with this is that it does not account
for the use of Request Headers within PUSH_PROMISE frames. This is
minor right now, but it means that PUSH_PROMISE frames will not have
optimum compression because the request headers will need to be added
as Literal representations with Indexing. It would be better if we
just had ONE prefilled table (it would make implementation generally
easier as well)

On Mon, Jul 8, 2013 at 1:33 PM, James M Snell <[e-mail]> wrote:
> So I've gone through and updated my header compression implementation
> based on the current spec. Some feedback (shouldn't be too surprising
> to anyone who may have followed my previous inputs on this topic)
>
> 1. I'd be *MUCH* happier without the Differential Encoding and the
> Reference Set requirement. These mechanisms are designed to further
> cut down on the number of bits set across the wire but they do add
> complexity to the implementation that I do not feel is strictly
> necessary. It would be possible to greatly simplify implementation if
> Differential Encoding and the Reference Set we dropped from the
> mechanism altogether at the cost of only a handful of additional bytes
> per serialized header block.
>
> 2. I'd be *MUCH* happier if Eviction in the Header Table did not cause
> renumbering of the existing items and if there was a fixed range of
> index positions. Roberto has argued that doing so gives much worse
> compression overall when dealing with lots of smaller valued headers
> but my testing against the current corpus of test headers has not
> demonstrated any significant problems. I will be drafting up a
> modified bohe proposal that describes what I'd like to see in detail.
>
> 3. Going with the fixed range of index positions would allow us to do
> away with the distinction between Literal with Incremental and Literal
> with Substitution indexing. Everything would essentially be Literal
> with Incremental until the fixed range is consumed, then the index
> would simply rollover to reuse the existing index positions. Yes, I
> get that the current scheme gives encoders more flexibility to develop
> alternative algorithms for management the header table but, so far, I
> do not agree that the flexibility is worth the additional complexity.
>
> - James