Does Discourse already support http3?
I know it’s primarily a network issue, but if I run Discourse on DigitalOcean, for example, the Docker container that Discourse runs in must be able to support http3
I don’t know, but how would http3 help Discourse?
Not at this time
2 Likes
Technically HTTP3 is just another version of the HTTP protocol. So if someone want to offer their Discourse instance over HTTP3 today, they can do that by putting a separate reverse HTTP proxy that supports HTTP3 in front of your Discourse instance. That is possible without changing the discourse docker image.
I’m guessing a bit here, so caveat that, but it seems that the docker image uses Nginx as a reverse proxy for Discourse internally. I see that Nginx supports HTTP3 natively, but considers the implementation experimental for the time being. Perhaps that’s why HTTP3 support in the docker image isn’t implemented for the time being?
https://nginx.org/en/docs/quic.html
2 Likes
Yes, it’s an experimental feature, but from tests on other sites, you can see that it’s already stable enough for projects that choose to go the http3 route today.
Is there any Docker maintainer for Discourse that I would host, if they could add http3 support as an optional feature, for projects that are interested in it?
A very nice article from which you can get an idea of the benefits to Discouse is here https://gcore.com/learning/what-is-http-3/
I have a general understanding of HTTP/3 and I know how and why it is useful with WordPress/LAMP, but I don’t understand why it would make a difference with Discourse.
Http3 reduces the latency when establishing a connection between the server and the client by up to 150ms. In addition, it saves server resources, as establishing http communication is more economical.
So the user will have a better community experience and the server operator will have less load. Win-win
Not at the moment, sadly.
I’ve kept a branch of our container HTTP/3-ready since (checks notes) 2019, which you can check at GitHub - discourse/discourse_docker at http3.
The reason we have not rolled that out widely is due to a collection of problems in the overall ecosystem:
-
Nginx development slowed to a crawl, and they are not keeping up with new web tech anymore, like HTTP/3 or Early Hints.
-
Nginx’s modular architecture meant that we could add it via a module, and my branch uses Cloudflare’s nginx module, quiche, for that. But Cloudflare has moved away from nginx too, and that module was never considered production-ready.
-
I considered migrating to a more modern web server, like Caddy, but changes like that are super hard when you release self-hosted software that people will customize.
-
Moving to HAProxy would be an easier sell, but we use nginx for static file serving, which HAProxy won’t do.
-
The fact that OpenSSL maintainers basically sabotaged QUIC and halted the progress of the entire ecosystem for the equivalent of a decade.
All the above, plus all the inherent problems of the TCP → UDP move that is part of this, meant that this change was too risky for us to take.
Which is super sad, given that in the average household of the last 4 years, most of the traffic is already HTTP/3, as every big player has migrated to it years ago, like YouTube, Amazon, Shopify, Instagram, Twitch.tv, etc. This further increases the gap between big tech and small sites, and it’s a shame that we weren’t able to be early adopters here, as we were with SPDY, HTTP/2, and Brotli.
Given all that, if you want an easy 1-click solution to this whole mess, you can use Cloudflare in front of your Discourse instance.
10 Likes
It pains me to hear that. I have a few ideas to explore. Can we discuss them?
- I would consider installing a module into Nginx, such as that would allow http3
- I would write to the Caddy community that your Discourse powers and ask them if they could help you with the transition to Caddy, it might be a win win partnership
QUIC is not supported - Help - Caddy Community
1 Like
The cleanest way to build it, which has potential to be something we eventually ship would be adding a new template that would be an alternative to web.ssl.template.yml, let’s call it web.ssl2.template.yml.
In this template, instead of modifying nginx, it starts an alternative web server, let’s say Caddy, which handles all the traffic and proxies to the nginx. This would allow a lot of experimentation, ability to test multiple web servers, and can potentially evolve into something we could make a default for new installs.
3 Likes
Sounds great. I’d love to get involved in testing. What are the next steps?
1 Like
Doing the work 
3 Likes
Another approach would be to add, to the docker image, a dedicated HTTP reverse proxy to handle HTTP3 traffic and only that. E.g, you could embedd say Envoy Proxy - which supports HTTP3 ingress - and configure it to listen only on port 443/udp for h3 traffic, and transform all incoming h3 requests to h2 or h1.1 and forward to the Nginx instance.
A bit of a hack though, so won’t say it’s a good idea.
2 Likes
Whichever way you decide to go, I think http3 is a good step and it will help the whole ecosystem. I’m looking forward to the next steps.