W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Negotiating compression

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Sun, 01 Jun 2014 17:30:21 +1200
Message-ID: <538ABA6D.3060808@treenet.co.nz>
To: ietf-http-wg@w3.org
On 31/05/2014 6:04 a.m., Roberto Peon wrote:
> The huffman design (using canonical huffman) was chosen such that replacing
> the table would be cheap (as transmitted on the wire), if, in the
> far-future it is needed to change tables, it will be cheap/possible.
> That is something to play around with, but not something that I'd guess
> would fit in the protocol today, as it has uncertain security ramifications.

As a result we need a halfway operation to prevent the existing huffman
table being used. The best proposal for that so far is the
disable-huffman SETTING. Which downgrades it from the existing table to
none rather that changing to an arbitrary alternative table.

The simplicity gained for naive implementations is an added bonus.


> -=R
> On Fri, May 30, 2014 at 9:30 AM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>> On 30 May 2014 08:05, Jason Greene <jason.greene@redhat.com> wrote:
>>> On this topic, has there been any consideration given to a potential
>> need to alter the huffman code table after release? Perhaps after real
>> world deployment someone determines that slightly different weighting would
>> lead to improved packet size. My apologies if this was discussed in a past
>> thread.
>> Yes, we put this in the "significant change" category.  That means
>> "h3", most likely.  If we bring back extensions, then there will be
>> other ways to move to an arithmetic coder or typed fields or something
>> crazy.
Received on Sunday, 1 June 2014 05:30:54 UTC

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