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

Re: Negotiating compression

From: Matthew Kerwin <matthew@kerwin.net.au>
Date: Thu, 29 May 2014 17:36:59 +1000
Message-ID: <CACweHNATNc8K+yv7wcUj28C=r72FuX7MG9skFMbnL8WqenjkTg@mail.gmail.com>
To: Willy Tarreau <w@1wt.eu>
Cc: Simone Bordet <simone.bordet@gmail.com>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On May 29, 2014 4:40 PM, "Willy Tarreau" <w@1wt.eu> wrote:
>
> 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.
>

I'm happy with this idea, as long as it doesn't start to do the
multiple-permutations or alpn-token-per-feature thing. How does it interact
with h2c, for example? (I'd suggest h2c implies h2h, and no fourth
variant.) I guess it's safe as long as there are no other non-negotiable
features *coughgzipcough* , or things that need a settings rtt to disable,
that need to be avoided independently from HPACK.

Perhaps it would be better to use h2f for failsafe mode, to make it clear
that h2 is the benchmark, and h2f is an acceptable variant/subset. It's
more of an all-or-nothing approach that way. It also fits the "add a
letter, remove a feature" pattern established with h2c and security.
Received on Thursday, 29 May 2014 07:37:33 UTC

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