- From: Nicholas Hurley <hurley@todesschaf.org>
- Date: Tue, 27 May 2014 11:31:57 -0700
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CANV5PPUAPeh-p-PiX6yLSVNeCKsQdpzOG8E=OyCy6ZqUEPUvDg@mail.gmail.com>
+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. > >
Received on Tuesday, 27 May 2014 18:32:25 UTC