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

Re: Negotiating compression

From: Jason Greene <jason.greene@redhat.com>
Date: Fri, 30 May 2014 10:05:03 -0500
Cc: Eliot Lear <lear@cisco.com>, Martin Thomson <martin.thomson@gmail.com>, Matthew Kerwin <matthew@kerwin.net.au>, Willy Tarreau <w@1wt.eu>, Simone Bordet <simone.bordet@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <C64103AA-694F-427B-9B0A-B3D29D9FBE12@redhat.com>
To: Michael Sweet <msweet@apple.com>

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

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