I've read a few answers on SF, and I'm no closer to a solution. My problem seems a little specific...
Customers were accessing a webserver on port 81. With the general trend towards HTTPS, the service was upgraded and installed on standard port 443. Crucially to my story, HSTS is enabled on the new HTTPS website.
On port 81, we put a simple Apache redirect:
ServerName example.com
RewriteEngine on
RewriteCond %{SERVER_NAME} =example.com
RewriteRule ^ https://example.com/ [END,NE,R=permanent]
It worked. Accessing http://example.com:81 will automatically redirected to https://example.com/
Thanks to HSTS, however, it works only once. I imagine that many users are accessing from links, bookmarks, cached Google searches... and are automatically being directed to http://example.com:81. Even my browser's autocomplete still likes to suggest the :81 link, so I'm guessing I'm not the only one.
Their browsers, having a valid HSTS policy performs an internal upgrade to the insecure request which results in the browser sending a request to https://example.com:81. This fails to load because of an SSL error - the port is not configured for SSL traffic.
I thus need a way to redirect http://example.com:81 AND https://example.com:81 to https://example.com
I have seen Webmin, when accessed via http://example.com:10000 give a custom error message about the site being active on HTTPS which is generated by Webmin and not the browser. Even if I could get such a page to load and implement a <meta>
refresh to the new URL, that would still please our users while the old URL plays itself out and is removed from links, caches and so on.