Re: Negotiating compression

On May 30, 2014, at 9:08 AM, Michael Sweet <msweet@apple.com> wrote:

> Eliot,
> 
> On May 29, 2014, at 12:57 PM, Eliot Lear <lear@cisco.com> wrote:
>>> ...
>>> I haven't seen any justification for creating a protocol variation.
>>> See Section 3.4 of RFC 6709:
>>> http://tools.ietf.org/html/rfc6709#section-3.4
>> 
>> That's really not the intent, if not the reading, of that section.  A
>> variation occurs within a protocol, and the key focus of that text is
>> one of assuring interoperability with means to identify among the
>> communicating systems that different rules in play.  Here there are
>> clear mechanisms to do that.  They are talking about a separate clearly
>> identified protocol.  Whether or not a separate protocol is warranted is
>> a different discussion.  Michael says yes.
> 
> I didn't say anything about a separate protocol.  I have filed an issue and mentioned on several occasions that I would like a setting (that can be passed in the initial HTTP/2 setup) to disable Huffman, just as we have a setting for the header table size.
> 
> I don't think that would be overwhelming to test or implement, and since we are already asking implementations to track header representations that must be preserved (literal headers without indexing) I don't think it would be stretch to have a way to say "do not Huffman compress at all".

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.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

Received on Friday, 30 May 2014 15:06:17 UTC