Re: Encouraging a healthy HTTP/2 ecosystem

MUST RESIST URGE TO JOIN CONTINUATION DISCUSSION....

On 1 July 2014 13:37, William Chan (陈智昌) <willchan@chromium.org> wrote:

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


I think that h2 is going to have an issue with extensions.   Because it has
been a deliberate design decision to conflate the framing layer with
application layer semantics, then it is simply not possible to expect any
extension to pass along a path that does not fully understand the
extension.    If you can't understand the framing without understanding the
protocol semantics, then intermediaries are not going to be able to forward
extensions that they do not understand.

So this can go several ways - either:

a) h2 goes out without any extensions.  Intermediaries will then be
implemented and deployed that have the HTTP semantics hard baked into the
framing layer, so that any future extensions will fail to deploy widely.
We will then see things such as websocket end up being send over perverted
HTTP streams rather than in dedicated streams.

OR

b) h2 will be deployed together with several extensions: websocket, frame
compression, large frames, large headers etc.  h2 Intermediaries will then
be developed with knowledge that extensions can and do exist, thus
hopefully limiting the deployment of intermediaries with hard baked HTTP
only support.  In such an eco system it might be possible to come up with
extensions that have non HTTP stream semantics and may succeed to get
deployed.    However it still creates a significant hurdle for them to
achieve some market presence so that the majority of intermediaries will
have extension plugins available, so I suspect that an initial batch of
extensions will get supported, after which time it will become impossible
to develop new ones and new ideas will need to pervert one of the existing
extensions to get through the h2 web.

OR

c) This WG will realise the error of conflating framing with application
layer semantics and the protocol is significantly rewritten.
Intermediaries can then be written that can work entirely at the
framing/stream level with little or no knowledge of the semantics of the
streams they are forwarding.  In such an environment, extensions for thing
like websocket can be written without the need for all intermediaries to
know of the extension.

I doubt c) going to happen, I fear that a) will, but hopefully Wills thread
will encourage the development of extensions in parallel so that b) might
happen.

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

OK I could not resist!   Seriously are you suggestion that clients
deliberately use continuations even when not necessary to take away the
option of servers/intermediaries to not implement a feature that is needed
only for very large headers?

I think something like
http://autobahn.ws/testsuite/reports/servers/index.html should be
sufficient to identify which clients/servers support which features.

regards

-- 
Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.