Websocket over HTTP2

[re-thc]

Hi, as per https://www.chromestatus.com/feature/6251293127475200 (think Firefox is looking into this too) is an enhancements to have Websockets served over HTTP2. Can this feature please be implemented?

https://tools.ietf.org/id/draft-mcmanus-httpbis-h2-websockets-00.html

Extracting the justification:

A server offering both HTTP/1.1 and WebSocket services can do so from the same instance and same port although they require separate TCP connections. Moving a server to HTTP/2 and WebSocket services requires a separate port and protocol stack for the sole purpose of bootstrapping WebSockets. This is a significant administrative burden and may not even be possible in the case of large amounts of deployed markup pointing at the old single name and port. Being able to bootstrap WebSockets from HTTP/2 allows one server, one port, and one TCP connection to be shared by both protocols.

[normanmaurer]

@hc-codersatlas we love contributions that said its a draft 00 so maybe a bit early for it.

[rschmitt]

The latest draft of the spec is available here.

[seamlik]

(think Firefox is looking into this too)

Will be supported by Firefox 65.

[rnd4222]

Given that it is no longer a draft, is there any chances it would be implemented in netty?

[normanmaurer]

@rnd4222 we love contributions... so if you feel you have the cycles go ahead. I am not sure when I will have time to look into it.

[infoLightspace]

Am up for the challenge. Am going through the draft.

[mostroverkhov]

for @hc-codersatlas and others interested in topic - recently I've experimented with rfc8441, and sharing results on https://github.com/jauntsdn/netty-websocket-http2

[riyafa]

@mostroverkhov why is this not a PR to netty?

[glennosss]

I recently implemented this, surprisingly with minimal effort. The hardest part of implementing was interestingly more due to how the current Websocket over HTTP/1 code was structured.

Current websocket code needs refactoring

The current Websocket over HTTP/1 code is overly coupled to HTTP/1 HttpRequest/etc.

It's fairly straight forward to separate the Websocket code so that it's separate from the HTTP/1 and HTTP/2 specific parts.

Websockets over HTTP/2

The first pull request someone should send in is simply to add;

• public static final char SETTINGS_ENABLE_CONNECT_PROTOCOL = 8; to Http2CodecUtil
• update Http2Settings to support this constant.

Adding this constant is the first step to adding Websocket over HTTP/2 support to netty. And if the previous refactoring is done, and some example code was provided, I don't think most people would have trouble enabling HTTP/2 websockets themselves.

The weirdest thing I found about Websockets over HTTP/2 is Chrome only establishes them if there's a current HTTP/2 connection it can multiplex over. If the server restarts or Chrome loses it's connection to the webserver, then Chrome will immediately (and annoyingly) default back to a HTTP/1 websocket connection. This means you must have a websocket server that also supports at least one HTTP request in order to support HTTP/2 websockets (further support for the argument that you shouldn't "optimistically setup your pipelines").

[glennosss]

@normanmaurer I'm recommending that two new incubator projects be created and wanted your thoughts.

Summary;

• Websockets over HTTP/1; https://datatracker.ietf.org/doc/rfc6455/ (supported by chrome)
• Websockets over HTTP/2; https://datatracker.ietf.org/doc/rfc8441/ (supported by chrome)
• Websockets over HTTP/3; https://datatracker.ietf.org/doc/draft-ietf-httpbis-h3-websockets/ (no chrome support yet)
• WebTransport over HTTP/2; https://datatracker.ietf.org/doc/draft-ietf-webtrans-http2/ (no chrome support yet)
• WebTransport over HTTP/3; https://datatracker.ietf.org/doc/draft-ietf-webtrans-http2/ (supported by chrome)

Ultimately in the future clients will prefer to connect using WebTransport (only supported by HTTP/3 for now), but fall back to Websockets if necessary.

I think the following repos should be created;

• https://github.com/netty/netty-incubator-codec-websockets
• https://github.com/netty/netty-incubator-codec-webtransport

Current state

[netty-codec-http] contains "io.netty.handler.codec.http.websocketx" package.

Future state: netty-incubator-codec-websockets

[netty-codec-websockets-http1] initially containing copy of "io.netty.handler.codec.http.websocketx" package.
[netty-codec-websockets-http2]
[netty-codec-websockets-http3]
[netty-codec-websockets-common] Most of the code for WebSocketFrame's/etc will be moved here. But with no dependency on netty-codec-http, netty-codec-http2 or netty-codec-http3.

Eventually remove "io.netty.handler.codec.http.websocketx" package from netty-codec-http.

Future state: netty-incubator-codec-webtransport

[netty-codec-webtransport-http2]
[netty-codec-webtransport-http3]
[netty-codec-webtransport-common]

[KingMob]

What's the status of this?

According to https://wpt.fyi/results/websockets/opening-handshake/002.html%3Fwpt_flags%3Dh2?label=experimental&label=master&aligned, RFC 8441 is now supported by all browsers other than Safari.

@mostroverkhov Have you considered making your repo a PR to netty?

[clayly]

We've also been seeing a trend of more 400 errors lately, perhaps clients are trying http2.