Question Details on http/3 activation and impact of that procedure on web server configuration files

[Bitpalast]

Server operating system version

Alma 8

Plesk version and microupdate number

18.0.71

On an Alma 8 test server that was updated to 18.0.71 I was hoping that I could activate http/3 on a per-domain basis as suggested in the change log. But it seems that the checkbox for it only appears after plesk bin http3_pref --enable -nginx was run on the console. However, that command applies changes to all virtual host configuration files. I am afraid that executing it on a production server with hundreds of domains will cause a significant downtime of several minutes, maybe up to 20 minutes, as we experience it when running "plesk repair web all" as in such a case all web server configuration files are rewritten, then the web servers restarted, and meanwhile websites become unavailable.

I'd prefer a solution where no service interruption is caused on domains that shall not be switched to http/3. Is that even possible? Or will we have to go through the downtime in order to make a selective http/3 per domain possible? What's is the idea behind offering a selective http/3 switch when this requires that first all web server configuration files must be updated. I'd think that offering a selective option is for avoiding exactly that, but not that I first need to have all files modified only to then get to the point where I can deactivate the option on a per-domain basis again.

Maybe I am wrong and the missing http/3 checkbox without prior console command is an error?

 

[Sebahat.hadzhi]

Hello, Peter. You are right, HTTP/3 needs to be turned on globally by plesk bin http3_pref --enable. I will consult with our team about your concerns on Monday and follow up with more details.

 

[Sebahat.hadzhi]

Peter, I discussed the matter with our team and, unfortunately, it is currently unavoidable to run plesk bin http3_pref --enable -nginx due to how the configuration system is architected. Enabling HTTP/3 globally is necessary to expose the per-domain control in the UI and backend.
The intent of the per-domain toggle is not to allow enabling HTTP/3 on an isolated, site-by-site basis from a disabled global state. Rather, the design assumes the administrator enables HTTP/3 server-wide, and then selectively disables it for individual domains that may encounter compatibility issues or performance regressions.
While technically feasible, implementing a mechanism to allow HTTP/3 to be enabled per-site without modifying all configuration files would require a substantial architectural shift and significant human resources, which is why during the development of per-domain HTTP/3 support, the option of moving to a global enablement model was chosen as optimal in terms of efforts and outcome.
The model that will exclude the vhost configuration is not entirely out of the question - our team is still evaluating it, but for the time being, there's no other alternative we can suggest.