Re: Alternative Header Compression Update..

Well, looking at Indexed references currently, the 256-entry table
means that every index position can be represented using a single
octet. If we represent each entry separately that means we would end
up always using two bytes to represent index positions > 127. If we
look at an example: Let's suppose we want to specify index references
for items 20, 40, 130, 140, 150 and 160...

Separately encoding using the current header compression scheme would be:

  94 a8 ff 03 ff 0d ff 17 ff 21

Using the grouped approach, we would encode as...

  86 14 28 82 8c 96 a0

Encoders are given the choice of whether to use the groups or not. If
the groups are not used, we end up encoding with 2 bytes per indexed
reference which means only two additional bytes relative to encoding
separately:

  80 14 80 28 80 82 80 8c 80 96 80 a0

While this is not as compact as the first option, I generally prefer
it because I don't need to worry about the variable length integer
encoding when I know my index position will never exceed FF.


On Thu, Jul 11, 2013 at 9:55 AM, RUELLAN Herve
<Herve.Ruellan@crf.canon.fr> wrote:
> James,
>
> The 256-entry table acting as a circular buffer is probably a cleaner solution than what is currently in the compression spec.
>
> For the low-level encoding of entries, I think I prefer encoding each entry separately using a few bits to signal which encoding is used. This is much simpler to use, and I would think slightly more compact.
>
> Hervé.
>
>> -----Original Message-----
>> From: James M Snell [mailto:jasnell@gmail.com]
>> Sent: mercredi 10 juillet 2013 02:40
>> To: ietf-http-wg@w3.org
>> Subject: Alternative Header Compression Update..
>>
>> All,
>>
>> Even tho we decided at the face-to-face to move forward with the header
>> compression draft as the starting point with header compression in http/2 for
>> the implementation draft, I definitely remain skeptical of the overall design
>> of the scheme. I have voiced my reservations in the past and after
>> implementing the current header compression scheme, my reservations
>> about it's design remain.
>>
>> Combining elements of my previous explorations here with ideas from the
>> current header compression draft, I have posted another update to the
>> "Stored Header Encoding" draft.
>>
>>   http://www.ietf.org/id/draft-snell-httpbis-bohe-11.txt
>>
>> This details an alternative scheme that ditches the differential encoding and
>> the reference set, uses a fixed range of header table indices (0x00-FF), and
>> uses a least-recently-written eviction strategy without renumbering. This
>> approach is significantly less complicated to implement at the cost of only a
>> small handful of additional bytes on the wire.
>>
>> - James
>

Received on Thursday, 11 July 2013 17:33:08 UTC