RE: Encouraging a healthy HTTP/2 ecosystem (and not arguing about CONTINUATION frames)

I really like what you’re trying to do here.  I’m not convinced it will work.  Here’s why:

·         Some percentage of clients will be HTTP/2 capable but not negotiate it anyway, because of MITM and proxies.  That said bumping down a percentage for telemetry purposes might not be a bad thing for an implementation to do.

·         Someone else (Willy, I think?) already identified the issue here.  There are no dummy extensions, just those that aren’t defined yet.  If you pick a random frame or setting number each time, you’ll *create* the ossification because you’ll interact poorly with someone who actually does implement that extension.  If you pick a specific ID, you’ll just force people to whitelist that extension.

While it’s a circular argument, I’m afraid the best way to ensure a healthy ecosystem as HTTP/2 grows is to start with one.  Make sure extensions are supported by defining some, and if people introduce new ones from time to time, so much the better.

From: willchan@google.com [mailto:willchan@google.com] On Behalf Of William Chan (???)
Sent: Tuesday, July 1, 2014 2:11 PM
To: HTTP Working Group
Subject: Encouraging a healthy HTTP/2 ecosystem (and not arguing about CONTINUATION frames)

Forking my thread to regain sanity :) Learning from my mistake and deleting the CONTINUATION frame bullet.

On Mon, Jun 30, 2014 at 8:37 PM, William Chan (陈智昌) <willchan@chromium.org<mailto:willchan@chromium.org>> wrote:
This has come up in a number of different discussions over time, and I thought it'd be nice to gather a list of things that it'd be useful if major implementations did in order to keep the ecosystem healthy. My interest is that, before lots of other vendors start implementing HTTP/2 and we start getting a plethora of crappy implementations doing dumb things and see actual deployment, we try to enforce good behavior so that when they deploy and do stupid things, it breaks for them. I don't want HTTP/2 to ossify the way that TCP options have essentially become undeployable. Here are some ideas for things to do:

* In order to encourage sites to do feature detection as opposed to UA sniffing, it'd be nice if major client implementations, some percentage of the time, choose not to negotiate HTTP/2.
* In order to prevent the extension mechanism from failing (due to intermediaries whitelisting extensions and disallowing all others, or some other sort of brokenness), it'd be nice for clients to negotiate random dummy extensions and, using out of band knowledge shared with the server, require that those extensions be negotiated. More than just negotiated, these extensions should probably use dummy logic like sending bogus extension frames and settings. A vendor that owned both an auto-updating client and popular website could enforce this.
* Make sure to use features that aren't necessarily required, in order to make sure they remain viable.

I feel like there were a number of other things that we wanted to do, but I forget. If anyone knows anything that they want early implementers to do in order to keep the ecosystem healthy, I'd love to hear.

Cheers.