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