Re: Re-work of op-code patterns

With the proposed change what would 0b1000000 signal?

If we are going to add a new opcode, I'd prefer to see the literal header
encodes both start with the same symbol:

1 - Indexed Header
00 - Encoding context change
010 - Literal Header without Indexing
011 - Literal Header with Indexing

Though I'm not sure why this is necessary -- seems like 0x80 is a clean
enough signal and can be followed by an arbitrary set of control opcodes
without expanding the compression size.


On Mon, Jan 27, 2014 at 8:19 AM, RUELLAN Herve
<Herve.Ruellan@crf.canon.fr>wrote:

> I created a new issue for better handling all the recent additions to
> HPACK, allowing for in-band signaling of changes in the encoding context:
> https://github.com/http2/http2-spec/issues/365.
>
> With these recent additions, I think a re-working of the patterns used for
> the different op-code could be more efficient.
> Current, we have 3 op-ocodes:
> - 1 - Indexed Header
> - 01 - Literal Header without Indexing
> - 00 - Literal Header with Indexing
>
> I would propose to add a 4th op-code, which would be used for signalling
> changes to the encoding context:
> - Empty reference set
> - Change maximum header table size
> - Empty header table
> - Padding
>
> The new op-codes would be:
> - 1 - Indexed Header
> - 010 - Literal Header without Indexing
> - 011 - Encoding context change
> - 00 - Literal Header with Indexing
>
> I did some quick testing, and changing the op-code for Literal Header
> without Indexing has only a very small impact on the compaction size.
> - For the mnot test-set: going from 29.62% of HTTP/1.1 size to 29.64.
> - For the hruellan test-set: going from 21.65% to 21.68%.
>
> I think this is a cleaner approach with a negligible compression cost.
>
>
> Hervé.
>
>