Re: 6455 Websockets and the relationship to HTTP

> On 2 Dec. 2016, at 11:56 am, Kazuho Oku <> wrote:
> 2016-12-02 9:19 GMT+09:00 Martin Thomson <>:
> On 2 December 2016 at 11:09, Mark Nottingham <> wrote:
> > In particular, my recollection of the outcome of the discussion of WS in H2 was that a new SETTING or a new ALPN token could be used to indicate that a connection supports both H2 and WS. If there's a problem with doing so, that would be good to talk about as well. Especially considering QUIC.
> There seems to be some reluctance to exercise that option.  I don't
> understand why; I've a bunch of candidate theories, but none of them
> make a lot of sense.
> My understanding is that the cons of using SETTINGS only is that it requires an additional roundtrip on connection establishment. I've heard people oppose to the use of ALPN since they want to use both H2 and WS (and possibly DNS?) on the same connection.

The semantics of the ALPN token can be "this connection supports H2 *and* WS."

It's true that taken to an extreme, this could lead to a combinatorial explosion. If I remember discussions at the time correctly, it was felt that having some positive pressure on implementations to identify and implement common profiles of protocols to support was a good thing.

> Personally, I think using both SETTINGS (or introducing a new frame) and ALPN solves the shortcomings (and the reluctance). We could consider ALPN as a method to specify the application protocol (e.g. HTTP or WS or DNS), and use SETTINGS for permitting additional protocols to be coalesced.

That's another way to do it too, provided the latency hit isn't critical. Since you've already got the H2 connection open in the typical case for WS, I think that'd work well, but I could be unaware of some use case that requires WS on the first RT.


Mark Nottingham

Received on Friday, 2 December 2016 01:01:13 UTC