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.

[shareable-vision]

Howdy, Ya'll!

I am curious how the merging of HTTP/3, QUIC is going 🥹

This may sound like a bizarre line of questioning, but seeing as how UDP/QUIC protocols are often used for P2P communications . . my team and I are very curious about the possibility of serving HTTP requests directly between peers without depending on DNS and rendering such dynamic P2P hypertext in an alternative environment to the Chromium browser, like say: a Tauri application. We really like the idea of P2P publishing and are currently writing a web authoring framework called Situs that intends to majorly simplify web authorship for the common folks, the pioneers and cowpokes out on the range.

Does that sound outside the realm of possibility or merely outlandish?

[essen]

The branch has been merged and HTTP/3 can be used in current master. Browser support for Websocket over HTTP/3 is lacking though so that has slowed down my efforts a bit, but I have been integrating it in RabbitMQ. There's still the matter of "listeners" to be solved as well, whereas the current implementation doesn't provide nearly as much functionality as Ranch.

I don't really know the context around your question so hard to say much that is useful, but HTTP/3 is still HTTP, meaning it is a client/server protocol. I am not sure it would fit for P2P.

[shareable-vision]

That's awesome! Probably not released as of v2.12.0?
Will wait for it to land in a coming release 🙏

Yes, but a peer running an accessible web server, becomes a server . .

It's an experimental concept. Thanks for entertaining the question.

[essen]

It is in the current master only.