- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Sun, 01 Jun 2014 17:30:21 +1200
- 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. Amo > > -=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