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

Re: Negotiating compression

From: Kennedy, Smith (Wireless Architect) <smith.kennedy@hp.com>
Date: Thu, 29 May 2014 15:35:21 +0000
To: Willy Tarreau <w@1wt.eu>
CC: Martin Thomson <martin.thomson@gmail.com>, Simone Bordet <simone.bordet@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <F0C167C4-2D4F-42E6-B63A-AA9D7C12605E@hp.com>


On 2014-05-29, at 12:34 AM, Willy Tarreau <w@1wt.eu> wrote:

> On Wed, May 28, 2014 at 10:32:44AM -0700, Martin Thomson wrote:
>> On 28 May 2014 02:41, Simone Bordet <simone.bordet@gmail.com> wrote:
>>> Can you please expand on what is plan B in the unlikely event ?
>>> I am guessing that it would require to bump the HTTP version, and a
>>> worldwide update of all servers to the new version (or drop to HTTP
>>> 1.1) ?
>> That's extreme, but I think reasonable.  Given that you are talking
>> about trying to force behaviour on a counterparty, I don't see there
>> being any virtue in finer grained control over counterparty behaviour.
> I tend to think that a failsafe, non-optimal fallback without the bells
> and whistles could significantly drive adoption. Devices could start by
> only supporting this minimal subset, and later implement the large one.
> These ones could be advertised in the ALPN name (h2 = failsafe, h2h =
> hpack version for example) so that we don't need an extra round trip
> to know what is supported.
> That way if a CRIME-like attack surfaces, simply disable h2h for the
> time it takes to design a new encoding and applications relying on
> passing everything in the same connection continue to work, just
> slightly slower.
> And devices with limited capabilities can only implement the non-optimal
> mode which is cheaper for them.
> Willy

Received on Thursday, 29 May 2014 15:36:43 UTC

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