To restate my comment in more precise terms, users do not care which protocol of { HTTP/0, HTTP/1, HTTP/2, HTTP/3 } their browser selects and uses when communic

To restate my comment in more precise terms, users do not care which protocol of { HTTP/0, HTTP/1, HTTP/2, HTTP/3 } their browser selects and uses when communicating with the remote server at whatever URL they entered. They expect the URL to work, and they don't care how. The Unifi issue you cite is due to a series of problems that are related to the http:// http:// to https:// https:// migration, most of which Unifi could have easily discovered and mitigated had they cared to. I'm really disappointed in Unifi here, but the browser is at fault, too. First: Your browser's fallback process for handling "the user entered an invalid URI" is attempting http:// http:// first, rather than https:// https:// first. Second: The Unifi is responding over http:// http:// with a completely useless error page, rather than a redirect to https:// https:// at the same port. Third: The Unifi probably isn't setting a Strict-Transport-Security header on responses to https://:8443 https://:8443, which means that your browser can't learn a better default. Fourth: If the Unifi's instructions tell you to enter "unifi.home.arpa:8443" rather than "https://unifi.home.arpa:8443 https://unifi.home.arpa:8443", their instructions are clearly wrong. (If you're not following their instructions precisely as written, that would explain your discover of the prior three; I can't say I blame you — I would have left it off too.)