Re: Negotiating compression

-1

You might be able to fix your end, but how do you tell the other side to stop?

Right now you can set the header table size to 0 (good), but you can't disable Huffman (not so good). The fix for Huffman would just be a parameter in the initial SETTINGS frame.

And the issue is not just complexity but overhead - Huffman coding alone requires relatively slow bit manipulations, the header tables add to the memory overhead of every connection, and proxies get to do header processing twice...  Not a big deal on a desktop machine with a dozen connections, but embedded devices and proxies have tighter constraints.


On May 27, 2014, at 2:31 PM, Nicholas Hurley <hurley@todesschaf.org> wrote:

> +1
> 
> HPACK is not so horrendously complex that it should be considered a barrier to entry (it's actually pretty simple, even including Huffman encoding). Plus, I can always start sending only literal encodings if the security situation suddenly becomes an issue.
> 
> Not to mention the fact that, the more things that can be negotiated, the more possibility there is for state mismatches at each endpoint, and the more possibility there is to break interop (even with ACKed SETTINGS).
> 
> --
> Peace,
>   -Nick
> 
> 
> On Tue, May 27, 2014 at 10:54 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
> The long and rambling thread on schedule has again started to discuss
> HPACK.  A point was made regarding negotiation for its use.
> 
> I don't think that negotiation is necessary.  The argument regarding
> the physics, which would dictate the use of an entire RTT for
> negotiation, is compelling, but I have others.  The only reason you
> want negotiation is if you want to be able to influence the behaviour
> of a counterparty.
> 
> A sizable advantage can be gained by modifying your own behaviour,
> which HPACK always permits.  Given that the data you care most about
> protecting is usually the stuff that you send, I'm willing to bet that
> this is good enough in the unlikely event that an attack is
> discovered.
> 
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair