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

Re: Negotiating compression

From: Simone Bordet <simone.bordet@gmail.com>
Date: Thu, 29 May 2014 09:02:58 +0200
Message-ID: <CAFWmRJ1WW7P_EsX3hi2y2pwjyMnK0PjuQ07h3X6HqotiutHSDA@mail.gmail.com>
To: Willy Tarreau <w@1wt.eu>
Cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>

On Thu, May 29, 2014 at 8: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.

I wholeheartedly agree with this approach.
There need not to be a full negotiation mechanism, h2 and h2h are
enough for now, and failing that negotiation, fall back to HTTP 1.1.

Simone Bordet
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz
Received on Thursday, 29 May 2014 07:03:28 UTC

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