Will Ubuntu 22.04 support HTTP v3?

I heard that HTTP v3 is great for mobile networks (switching hot spots often).

Which new Linux versions will support this? Will ISPConfig v3.2.x support newer Linux version with built-in HTTP v3?

 

If I am not mistaken, other than web server support, browsers and may be dns servers might be related as well. Cloudflare had it since 2019 and most browsers already supported it.

 

I'm using OpenLiteSpeed as a reverse proxy in front of my webservers to serve several websites over HTTP3 to the clients.

Although in my case it's a separate VM, you should be able to implement it on the same host as your ISPConfig installation if you let Apache or Nginx (whichever you use) run on different ports than 80 and 443 with some tweaking of the configs.

There's no way to configure OpenLiteSpeed from within ISPConfig. You need to do that manually or script it somehow.
But running it on the same host does give you the advantage to simply use the same certificate files in OpenLiteSpeed that you created with ISPConfig for HTTPS.

 

ISPConfig does not support dual web server in a host, if that you were trying to say, for the reason that was already mentioned several times in various threads. Logic also dictates that running multiple web servers in a single host will definitely use more resources.

I have been using http3 since CloudFlare offer it as beta and I don't have to have multiple web server in a single host at all.

 

Are you saying it's mandatory for ISPConfig to function the supported webservers Apache or Nginx need to be running on port 80 and 443 and not for example 8080 and 8443? I find that hard to believe.
During install ISPConfig is looking for installed binaries to determine if Apache or Nginx is installed, not which port they're running on as far as my experience goes.

A while back I was playing around with a customized Nginx on a alternate port to test HTTP3 support and when I updated ISPConfig because of a new version it decided to switch from using Apache to Nginx.

As I said it would need some tweaking. Custom config files for vhost at least when running Apache (which ISPConfig supports).
And if you're running Nginx maybe not even that as ISPConfig lets you set ports to be used when creating a website.
After that you should be able to run anything on port 80 and 443.

Although this is all theoretical I can't see any reason why this wouldn't be possible.
If I'd had the time I'd gladly make it a test case. But unfortunately I haven't.

You're absolutely right about that.
And my guess is you're not only using Cloudflare for it's HTTP3 support. Others can have several reasons to use or not use Cloudflare.

 

That was not what I said and you clearly twisted it, and really deviated from it, a lot.

Anyway, that is your server so do it your own way.

 

I started with a legit question to find an answer on why you say ISPConfig does not support dual web server in a host.
There was no intention to twist anything.

 

That is to me a clear twist and real deviation from what I said, because what I said is very much clear and straightforward.

But your post clearly did, so your question is not at all legit. It is a known fact that ISPConfig does not support dual web server in a host. You can modify or script whatsoever you are capable of to make that works on your own server but, a fact is a fact.

 

The only fact about dual webserver is you need to choose between Apache and Nginx in your base installation as ISPConfig can only manage one and not both.
Using port 80 and 443 is not mandatory as far as I know.
Nowhere I made a statement to install both.
So your statement about no dual webserver, besides you can't have both Apache and Nginx, still remains unclear to me.

If you tweak the right way to make your base install with ISPConfig run on other ports than 80 and 443 you make use of default ISPConfig capabilities only to configure your websites from within ISPConfig to use the right alternate ports and do only config changes outside ISPConfig that won't interfere with ISPConfig install and update scripts.
Then you have port 80 and 443 free for OpenLiteSpeed as a reverse proxy.

I'm not saying everyone should do this. I'm just pointing out a possibility for those who realy realy realy want HTTP3 support within their own system.
Which by the way I've not implemented myself in this way as I'm lucky enough to have plenty of resources to run OpenLiteSpeed on a separate VM.

 

Aaaaanyway...
Aye, I'm currently running my own patched nginx on ISPConfig3, serving a few sites with HTTP/3 (experimentally), while the remaining ones, of course, are behind Cloudflare (so I don't need to worry about them).
I added my own nginx vhost custom template to be able to add HTTP/3 as an option (it even works sometimes ), so, on that side of the equation, things are reasonably easy to deal with.
The culprit here is nginx itself.
Correctly patching nginx to get it to support HTTP/3 in a consistent manner and remaining as stable as before (falling back to HTTP/2 if there are issues negotiating HTTP/3; and, of course, keeping to serve HTTP/2 and even 1.1 on demand for the remaining, non-HTTP/3 sites) is... well, a nightmare. No, let me rephrase that: it's an utter nightmare, one that will haunt you for weeks and months, scratching your head until the hair falls off and your scalp starts to bleed... you get the picture.
It is possible, though. It's just tremendously hard. You won't get much help on the Internet, either. Every interested party is trying to make it work in the simplest way possible — but there is no simple way.
Besides having a current source tree of nginx to start with, you'll need Microsoft/Akamai's fork of OpenSSL, known as QuicTLS, and which basically extends OpenSSL with QUIC (the underlying Google/Microsoft API for dealing with what is now known as HTTP/3).
You might wonder why use a fork of OpenSSL. Well, for some unfathomable reason (don't ask), the OpenSSL maintainers have something deeply against HTTP/3. It's not something rational (IMNSHO). They might — or so Microsoft, Akamai, and possibly even Google hope — in the future decide to include QUIC in the 'core' OpenSSL again, and, when that happens, all the code is already available for that. But this hasn't happened in the past 2-3 years and nobody knows if it ever will happen; the OpenSSL team is pursuing their own agenda & roadmap instead.
The 'good' thing about QuicTLS is that it's a pure replacement of OpenSSL. Well-written code should not even notice a difference (except that the openssl command-line client will now have a +quic flag set). Theoretically, therefore, you can compile nginx with QuicTLS and everything should work fine — the compiler will not notice any difference. Right?
Well... yes to a degree, assuming that the only functionality you wish from nginx is to also serve HTTP/3.
In my use-case scenario, that's not enough. There is PageSpeed to deal with. There is a handful of essential nginx modules, none of which are bundled on any repository (much less a LTS from Ubuntu!). Some of those can only use OpenSSL. Others insist in using LibreSSL. Some want both. And a few refuse to 'believe' that QuicTLS is merely a fancy port of OpenSSL and nothing new, thus failing to compile — much less to produce a working, stable executable!
There are alternatives to nginx + QuicTLS, obviously. One of the most popular methods is to use Cloudflare's own QUIC patch, which, at least, is field-tested, serving hundreds of millions of websites, and billions of users every day. Alas, the nasty Cloudflare crew has done their work... in Rust.
Nothing bad about Rust in itself, of course (I'm not a fan, but then again, I'm not a fan of many popular programming languages either...). It generates clean, fast, efficient code, almost as good as C/C++, in a portable module with a light wrapping around it. Most code compiled in C/C++ will not mind 'talking' to a Rust-compiled library at all.
There are notorious exceptions, one of which being... well, OpenSSL.
Bummer! Cloudflare doesn't really bother about that, because they use LibreSSL anyway, and nginx can be compiled with LibreSSL, too, so it works for them. However, modules such as PageSpeed require OpenSSL to work (or, rather, refuse to compile together with Rust-generated code). So, if you wish QUIC + PageSpeed, forget that route — it doesn't work, or, at least, didn't work a year ago, when I made my last attempt to build everything together
Things obviously get more complicated as you add more esoteric modules, of course — some will work only with OpenSSL, some will hiccup on QuicTLS, some will work with LibreSSL but not with patched Rust code, some will compile with Cloudflare's QUIC patch but not allow HTTP/3 to be activated... some will refuse to work with PageSpeed if and only if PageSpeed is using QuicTLS (but be fine with plain old OpenSSL), but accept a patched nginx + LibreSSL (so long as PageSpeed is not present...) and as you add more modules, the complexity becomes exponential...
I'm still owing the GitHub community an answer to their question of my 'cookbook' — how I did manage to get it all compiled. Believe me, it wasn't easy, and, of course, I never took notes... so, the truth is that I don't fully remember how I did it — lol
What I know was that I was using a nice little script that would assemble a ready-to-deploy nginx executable by selecting all the modules I needed, and my initial approach was to use that script and just patch it slightly (it did already support HTTP/3 to a degree, but, for me at least, it was highly unstable, and took ages to compile, because it would bring all the source code for the Rust compiler, compile that first, and then proceed to compile Cloudflare's QUIC patch... and remove everything at the end, so, if you wished to run the compilation a second time, it would need to download everything again, and so on, and so forth...
Anyway... if you only wish to use HTTP/3 and don't need any fancy extra modules, your best choice is to use the nginx 'official' binaries for Ubuntu. I haven't tested them myself, so I haven't checked what modules come with them; but at least they'll save the weeks of nightmares I had until I managed to compile nginx with QuicTLS
From the perspective of adding support for HTTP/3 on ISPConfig3 itself... my recommendation would be to wait a little longer. The nginx core team really wants to support HTTP/3 and is doing their best to come out with a reasonably stable version, it's just that We Are Not There Yet. Until that happens... I'd stay away from it on a production server running ISPConfig3 for paying customers, you'll just be inviting trouble at some point.
But if you're insane like me and don't worry much about what customers think of their service (mine are mostly non-profits and tiny, poor organisations that don't pay me anything, anyway), then, sure, by all means, go ahead and tinker with it at will, just remember to have your backups at hand — because you will need them

 

I guess a test environment is possible if you wish to try it on your own server but I would wait until it is fully integrated in nginx via official repo or Ondrej Sury repo at least. Personally I use the later in my ISPConfig nginx web server to get the latest but it is not advisable for production.

 

@ahrasis you're obviously more than right; I personally can afford to have "temporarily broken configurations" on my always-in-perpetual-beta-testing environment
The good news (which prompted me to add this comment here) is that, while Ubuntu 22.04 of course doesn't ship a more recent version of nginx, Ondrej Sury does support the latest of the latest, and, aye, 1.25.3 does come with HTTP/3 support, out of the box so to speak, no compilation necessary! Hooray!
There is a downside to it, though; nginx 1.25.3 introduced a change in the TLS configuration, which does have an impact on ISPConfig's own default vhost templates; you need to tweak them properly. But that's outside the scope of this thread, and I promise to add a new one, which will also address the shifting paradigm regarding how to properly deliver a web page these days
Stay tuned...

 

Then, join the developer team at once.