Encouraging a healthy HTTP/2 ecosystem

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. For example:
  - If we think servers need to at least be able to support reading
continuation frames (if not necessarily use them themselves), then clients
should make sure to exercise this code path some part of the time.

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.

Received on Tuesday, 1 July 2014 03:37:48 UTC