Re: hpack huffman codes

It costs nothing to disable Huffman coding. Thus the table really isn't the
issue. The actual problem here is the grammar of the various header fields,
and the potential need to translate into HTTP/1.1.
On Jun 10, 2014 7:49 AM, "Martin Nilsson" <nilsson@opera.com> wrote:

>
> Regarding the process to validate the current hpack huffman codes against
> a large set of real headers, I think there is a risk that we'll paint
> ourselves into a corner dictated by how HTTP/1 looks like. As pointed out,
> a lot of base64 or hex encoded headers greatly benefits from huffman
> encoding. However, if we can carry binary data there is no point in having
> the data encoded in the first place, and not something to train the code
> table for. These headers will change over time, because even if they are
> taken into consideration for the huffman table, it is still more space
> efficient to not encode them. The code lengths for the characters of the
> other headers might suffer though.
>
> /Martin Nilsson
>
> --
> Using Opera's revolutionary email client: http://www.opera.com/mail/
>
>