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

Re: Negotiating compression

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

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