The decisions made in RFC 6796, 8.1 are much easier to comprehend, if you imagine what would happen, if a HSTS header from an HTTP response was handled the same way as with HTTPS:
The site is HTTP only, and accidentally adds a HSTS header. The browser would now be instructed to upgrade to HTTPS, but the site is not serving the HTTPS version at all, and becomes unreachable.
A man-in-the-middle (MitM) adds this header, making the site unreachable on purpose.
As a man-in-the-middle could also do the same on an HTTPS connection, when user bypasses a warning making a security exception, the RFC 6796, 8.1 has two conditions:
The HSTS header must be received over a secure transport (not plain HTTP).
There must be no underlying secure transport errors or warnings. As, after enforced, HSTS requires the same conditions, as described in 8.4, having any errors or warnings allowed during reading the header would also make the site unreachable, whether it's accidental or caused by a MitM.
Therefore, the only reasonable usage of HSTS is:
- First redirect HTTP to HTTPS, then redirect to the canonical name over the HTTPS.
- Add the HSTS header to all the HTTPS hostnames, not just to the canonical hostname. This way you'll be protecting all the hostnames. Otherwise, an unprotected version could still be used for MitM.
- If all the redirecting hostnames are subdomains of the canonical hostname, and if you don't need any subdomain over plain HTTP, add the
includeSubDomains directive to protect them all at once.
- Consider HSTS preloading. It has two phases: adding the header & submitting to the lists.