(2021)

Unfortunately nginx's HTTP3 support is still considered experimental years later though. Feels like F5 are asleep at the wheel at this point.

Nginx ingress, arguably the most popular reverse proxy for Kubernetes, is also lacking any HTTP3 support because of this slow progress. The related issue is 5y/o and the feature is now planned for its successor. https://github.com/kubernetes/ingress-nginx/issues/4760

Wow, I didn't realize that about nginx. I've been using HAProxy with http3 for several months, and it's supported http3 for over 2 years.[0]

[0] https://www.haproxy.com/blog/announcing-haproxy-2-6, also https://haproxy.debian.net/

Yes, note that the caniuse screenshot in the article is outdated: https://caniuse.com/?search=http%2F3

Safari supports HTTP/3 since v16

I didn't catch this until I got to the part about OpenSSL 3 being delayed... I'm not sure I see much value in reading about how HTTP/3 support was in 2021, and without (2021) in the title it's more misleading than anything

It's still not part of Go's core http library, btw. Which is funny, considering both QUIC and Go is made by Google, but I understand it's a big org.

same goes for webp.

HTTP/3 is enabled in the curl package on Debian:

https://samueloph.dev/blog/debian-curl-now-supports-http3/

Daniel also has a more up-to-date post on HTTP/3:

https://daniel.haxx.se/blog/2024/06/10/http-3-in-curl-mid-20...

HTTP/3 support is a bit frustrating, since it's highlighted a serious split in engineering effort & focus, which has created a two-tier internet: browsers & big CDNs do support and use HTTP/3 heavily, but most small tools, servers and programming languages don't have stable built-in support at all (e.g. no support in the standard libraries for Go, Node.js, Python, etc) for either clients or servers. Even big tools like Nginx only have experimental support, disabled by default: https://nginx.org/en/docs/http/ngx_http_v3_module.html

Many years after this article was posted, OpenSSL does now have QUIC _client_ support (from 3.2: https://github.com/openssl/openssl/blob/master/README-QUIC.m...) but server support is still not available (and for Node at least, OpenSSL's approach here has been one of the main blockers for serious built-in HTTP/3 support).

There are some native libraries you can use to work around this, but they're not easy to set up in many cases and they're totally separate from each languages normal network stack. As a typical developer, the general solution is still 'just use HTTP/2 everywhere', even as HTTP/3 use on the browser web spikes higher and higher.

OpenSSL shouldn't be trying to develop a quic stack but expose the API all other projects can use.

I didn't know HTTP/2 had caught on. I thought the current meta was HTTP/1.1 by default, and HTTP/3 if you need it.

It's all HTTP/1.1 at the application layer, still. The HTTP/2 and HTTP/3 are mostly a binary encoding scheme (to use on top of good old TLS on top of TCP) and a different transport protocol (on top of UDP instead of TCP), respectively, but their goal is to carry good old HTTP/1.1 messages around.

Not exactly. HTTP now has multiple substrates some with different features and documents describe the mapping of HTTP onto each substrate.

It depends on if your tools make it easy. For example in Go the default http client and server basically just enable HTTP/2 by default.

My understanding is that bradfitz championed that.

.Net has both QUIC and HTTP/3 support.

My main reason is because there is no support for it in Ruby yet, been waiting for a while. Usually I would try to release such a missing gem myself but HTTP/3 is waaay to complex for me.

Also, I remember when asking for why there was no support for HTTP/3 yet in Rails, someone responded something along the lines of no true benefit of using H3 over H2. But I can't find that comment again.

Do you mean server or client?

On server side I think I handle it in reverse proxy and/or CDN.

Client side I don't see anything HTTP/3 related yet.

Server

I'm really missing HTTP/3 in ingress-nginx for Kubernetes. I guess most people use a CDN/Load Balancer in front of it. I didn't find a good general purpose alternative for ingress-nginx yet.

(https://github.com/kubernetes/ingress-nginx)

This spreadsheet is outdated, but there are some general purpose ingress projects listed with HTTP/3 support if I'm not mistaken: https://docs.google.com/spreadsheets/u/0/d/191WWNpjJ2za6-nbG...

I know this list, and I always came back to ingress-nginx after trying out an alternative. ingress-nginx works best for me, it just doesn't have HTTP/3 and it doesn't seem to be a priority for the project.

I guess most people just use Cloudflare or similar Gateways for HTTP/3 support, which is probably the best option for now.

Misleading OP (2021)

Then: https://news.ycombinator.com/item?id=40632272

And what's newer since then:

2024: https://daniel.haxx.se/blog/2024/06/10/http-3-in-curl-mid-20...

What do I have to do to support H3 in my app? Is this like TLS, which is terminated by some reverse proxy and the application still just uses http 1? Or does it have to be in the application itself? IIRC H3 requires TLS, so it might be better at the reverse proxy? But do I still get the benefits of H3 if I do that?

Since the connection between your reverse proxy and your application server is probably much more reliable and lower latency than between your user and your reverse proxy, you should still benefit in the typical reverse proxy setup.

That's how I use it

Envoy as TLS terminating reverse proxy, and then locally it does http2.

Not sure if this could work for you, but I use HAProxy (not for failover, but just as a front end). It terminates TLS and supports http3. I was already using it for http2 (TLS required for that), so enabling http3 involved upgrading and editing the config a little bit. I'm pretty sure the web servers behind it use http1.1 to HAProxy, then HAProxy talks http3 to clients.

https://www.haproxy.com/blog/announcing-haproxy-2-6

https://haproxy.debian.net/

Live example: https://theandrewbailey.com/

It will be better with a reverse proxy. Decoupling the app and the ingress is always a good practice when you can afford an extra layer. The app itself is sufficient with HTTP/1.1 if the internal network is secure and performant (which it almost always is a container network nowadays).

iirc there were some benchmarks for quic vs standard http1/2 and the quic was essentially on par. the only thing it provided was faster something(really don't remember) but overall there was no difference to the client.