• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Resolved http/3 supported by plesk?

My lord I solved it ~~~
:D
~~~
So let's consider that solved ;)

The main takeway is that Almalinux seems to have firewalld / firewall-cmd from the get go, which seems like a bit of pain in this all.
iptables / plesk firewall + host firewall ... all do what they should and be the only ones needed.
Congratulations for sticking with it until resolved :cool:
It was just a small (by comparison) misconfig issue as was suspected from the start. We couldn't have helped you in any way or traced the specific cause (Almalinux / firewalld) as we're running Ubuntu (as per previous caveat) but that doesn't matter. You resolved it technically, yourself. That's more rewarding.
 
I have tried to check my website (which already has HTTP/3), but the result is "Peer reports incompatible or unsupported protocol version". Very strange, but to understand more, we need more details from the tool side.
Definitely not in your case, but some people, depending on their own testing devices' OS and its browsers' setups, may not be able to test for HTTP/3 (yet) but may not be aware that they can't... That then ends up with false test result for them, when they test their servers remotely using these devices / OS - AKA - People can / should setup & validate their browsers first (with browser HTTP/3 tests) and then run their own, remote server HTTP/3 tests, afterwards. The caveat here, is that they are not using any internet connection (i.e. ISP / Modem / Router etc) that does not allow or support HTTP/3.

We only use macOS / iOS devices, so can't comment on others, but having checked and configured browsers to suit in advance, currently, Chrome (for Mac) always gives the most consistent, valid HTTP/3 test results for us. This will change, obviously, as HTTP/3 popularity increases / in general use everywhere.

Simple HTTP/3 browser tests can be run here: https://http3.is/ (may need an initial refresh) and here: https://quic.nginx.org/ (Top of the page, clear indication) and a detailed test can be run here: https://quic.nginx.org/quic.html just to be sure (attached image, tests taken on: iMac / Sonoma 14.5 / Chrome for macOS).

Once the OS browser is verified, those remote server HTTP/3 tests can be made here: HTTP/3 Check here: HTTP/3 Test | Ensure Your Website's Speed and Compatibility or via any of the methods (including api) detailed here: How to Test if a Website Supports HTTP/3? Our own preferred test method is not to use browsers, but to only to use Curl, which is consistent, detailed & 100% accurate. However, just for this post, we did run tests on our own servers using the aforementioned website: Check Website Speed. Performance optimization made easy - GetPageSpeed and did achieve the correct HTTP/3 test results.


quic.jpg
 
~~
FWIW If we run a HTTP/3 curl test, one of our sub-domain Plesk Login Pages and on port 8443: iMac:~ zqx$ curl -vDI https://***.*****.***:8443 --http3-only
Then it does provide all of the expected (full) results, on both IPv4 and IPv6, on port 8443, all without any issues or delays, so thanks Plesk. Much appreciated.
~~
Update 3 to Plesk Obsidian 18.0.61 means that paragraph above ^ has been now revoked by Plesk. This only applies to HTTP/3 on the Plesk Panel itself (when it's on port 8443, as is the previously posted paragraph above) and NOT all of the hosted domains / sub-domains (on port 443) themselves. There are some other reasons linked to this revocation, but these are not stated on the change log. In theory, this will be invoked again, once Plesk has fixed all of the reasons.
 
Back
Top