Why does the RFC prohibit the server from sending HSTS to the client over HTTP?
I can see that if a HTTP client responds to that unsecure HTTP response it might cause that site to be inaccessible to the client, but I don't see any reason for the server to have a MUST in the protocol.
Rather the client MUST NOT respond to HSTS in unsecure HTTP responses is the correct approach in my mind. What am I missing?
If an HSTS Host receives an HTTP request message over a non-secure transport, it SHOULD send an HTTP response message containing a status code indicating a permanent redirect, such as status code 301 (Section 10.3.2 of [RFC2616]), and a Location header field value containing either the HTTP request's original Effective Request URI (see Section 9 ("Constructing an Effective Request URI")) altered as necessary to have a URI scheme of "https", or a URI generated according to local policy with a URI scheme of "https".
NOTE: The above behavior is a "SHOULD" rather than a "MUST" due to:
Risks in server-side non-secure-to-secure redirects [OWASP-TLSGuide].
Site deployment characteristics. For example, a site that incorporates third-party components may not behave correctly when doing server-side non-secure-to-secure redirects in the case of being accessed over non-secure transport but does behave correctly when accessed uniformly over secure transport. The latter is the case given an HSTS-capable UA that has already noted the site as a Known HSTS Host (by whatever means, e.g., prior interaction or UA configuration).
An HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over non-secure transport.