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>
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.
>
>
>