Re: 6455 Websockets and the relationship to HTTP

On Thu, Dec 01, 2016 at 08:34:26PM -0500, Patrick McManus wrote:
> On Thu, Dec 1, 2016 at 8:00 PM, Mark Nottingham <mnot@mnot.net> wrote:
> 
> >
> > 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.
> 
> 
> 
> Doing it with settings on alpn=h2 is a little tricky.. if you need to make
> a new connection (e.g. you have none open) for wss do you do it with
> alpn=h2 and hope for the setting and then fall back to a new connection
> with h1 and upgrade if it doesn't work? That's a new pile of round trips
> for legacy servers. otoh doing it via alpn makes it easy by offering
> wsoverh2 and h1 in the handshake.. it also makes it easy for the h1 server
> to use alt-svc to advertise a better version elsewhere as we see quic do.

But I think that it's important to focus on the future, ie assume support by
default, and lose a round trip in case the assumption was bad. When properly
done, it adds the round trips only for old servers, giving incentive for
them to upgrade, without breaking compatibility.

Ideally we would need to use new frame types to create streams of type WS,
which would be rejected by an RST_STREAM by implementations not supporting
it.

Another possibility would be to define H2.1 which would support extra
protocols by default unless the server explicitly rejects them. That would
be immediately advertised by ALPN and servers would progressively move
towards this one.

Willy

Received on Friday, 2 December 2016 06:35:51 UTC