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

Re: Negotiating compression

From: Willy Tarreau <w@1wt.eu>
Date: Thu, 29 May 2014 08:34:15 +0200
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Simone Bordet <simone.bordet@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20140529063415.GK25451@1wt.eu>
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 06:34:41 UTC

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