Re: 6455 Websockets and the relationship to HTTP

2016-12-02 10:00 GMT+09:00 Mark Nottingham <mnot@mnot.net>:

>
> > On 2 Dec. 2016, at 11:56 am, Kazuho Oku <kazuhooku@gmail.com> wrote:
> >
> >
> >
> > 2016-12-02 9:19 GMT+09:00 Martin Thomson <martin.thomson@gmail.com>:
> > On 2 December 2016 at 11:09, Mark Nottingham <mnot@mnot.net> 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.


Agreed. While I believe it would be a good idea to have some kind of
mechanism to restrict the use of an H2 connection, a client need to be
forbidden for making an anticipation that the connection can also handle
HTTP requests. We have 421 that can be used as a safe-guard.
(Yes, this is the discussion we had with ORIGIN frame).

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.
>
> Cheers,
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>


-- 
Kazuho Oku