Re: Encouraging a healthy HTTP/2 ecosystem

Alternative suggestion that would likely be much more effective:

1. Don't fast track http/2 to last call. We collectively need more
widespread implementation experience. It's perfectly OK to let the
implementation draft sit for a while before pushing to RFC. If those of you
who favor the current draft as being complete and ready to go are confident
in your positions, then surely patience won't cause a problem, right? Who
knows, it might actually save us some trouble down the road on http/3.

2. Simplify more. Things like CONTINUATION are needless complication. Other
bits qualify as premature optimization. Remove those bits, define a proper
end to end extensibility model, encourage active experimentation and
finalize later on the bits we can reasonably agree will actually work.

3. Deal with intermediaries as first class citizens in the protocol. They
are a really that will not go away and cannot be worked around.

- James
On Jun 30, 2014 8:40 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. 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.
>
>
>