QUIC and HTTP/3

[heri16]

Would Cowboy be supporting HTTP/3 or QUIC?

Would there be an API to send/receive a raw multiplexed stream, or would WebTransport (modern Websocket) be supported?

Would the implementation be pure Erlang or using one of the below libs?

Name	Client	Server	Programming language	Company	Repository
lsquic	Yes	Yes	C	LiteSpeed	https://github.com/litespeedtech/lsquic
nghttp3	Yes	Yes	C		https://github.com/ngtcp2/nghttp3
h2o	No	Yes	C		https://github.com/h2o/h2o
libcurl	Yes	No	C		https://github.com/curl/curl
MsQuic	Yes	Yes	C	Microsoft	https://github.com/microsoft/msquic
proxygen	Yes	Yes	C++	Facebook	https://github.com/facebook/proxygen#quic-and-http3
Cronet	Yes	Yes	C++	Google	https://github.com/chromium/chromium/tree/master/net/quic
quiche	Yes	Yes	Rust	Cloudflare	https://github.com/cloudflare/quiche
neqo	Yes	Yes	Rust	Mozilla	https://github.com/mozilla/neqo

Interested to know more as looking for a reverse proxy that would support QUIC-stream (public) to Websocket (internal).

[essen]

HTTP/3 on top of https://github.com/emqx/quic for the first implementation. I am slowly working on it.

WebTransport is not likely to be ready / widely available for years. It's on my radar, but no plans for it yet.

[sendtopms]

@essen any update on WebTransport? Chrome 97 onwards supports WebTransport (https://chromestatus.com/feature/4854144902889472).

[essen]

WebTransport depends on HTTP/3. I have started HTTP/3 work but I have been busy with RabbitMQ work so it didn't get to a testable point yet. Also there's probably something that'll need to be done about QUIC to make it a more permanent thing than a NIF at some point... I will see if I can increase the time I spend on HTTP/3 to speed things up.

[aramallo]

Hi @essen have you ever consider bootstrapping WebSockets over HTTP/2 and HTTP/3?
I just spotted this https://www.ietf.org/archive/id/draft-hamilton-httpbis-h3-websockets-00.html. Does it have any merit to consider an implementation in Cowboy?

[essen]

Websocket over HTTP/2 is already supported. Websocket over HTTP/3 will be supported soon after I'm done with HTTP/3. It's not super difficult to implement.

[aramallo]

Oh awesome, I didn't know WA over HTTP/2 was done !!!

[essen]

The http3 branch has some HTTP/3 work done (a "hello world" handler works), though it requires the qpack Cowlib branch. But now I run into a chicken and egg problem where to test most of the features in Cowboy I need Gun to have HTTP/3 support. But perhaps I will first do an RFC 9114 test suite before going into a client-side implementation.

[essen]

The http3 branch is now in a usable state with most tests passing if anyone fancies experimenting. It may require Cowlib's qpack branch and Gun's http3 branch. Gun will not work standalone yet, it's using modules that are currently inside the Cowboy application.

WebSocket over HTTP/3 is also implemented in the Cowboy http3 branch.

I am taking a break to produce a new Cowboy release but my intent after that is to integrate into RabbitMQ.

WebTransport is still likely a few years away. In any case it's best to focus on HTTP/3 for now.

[m-2k]

WebTransport is still likely a few years away.

Nooo!

[bugnano]

FWIW I made a WebTransport server in Rust / Elixir, if it can be useful to somebody
https://github.com/bugnano/wtransport-elixir

[essen]

For what it's worth it shouldn't be too difficult to do WebTransport after HTTP/3 so depending on time constraints I might give it a go. However the last call for the draft isn't until July 2024 so there's time. The work needed to implement it doesn't seem big but it would have to be a new handler interface (due to having to handle both unidi and bidi streams) so it's not trivial either.

I am about to release Cowboy 2.11 and after that my focus will be on merging HTTP/3.