此客户端的行为是禁止的RFC的8.1节：

如果通过不安全的传输接收到 HTTP 响应，UA 必须忽略任何存在的 STS 头字段。

该规范禁止服务器发送不安全的 HSTS 指令，禁止客户端处理不安全的 HSTS 指令。这确保了服务器或客户端中的错误实现不足以破坏 HSTS；失败必须存在于两者中，弱点才会存在。

如您的问题所述，纯 HTTP 上的 HSTS 听起来像是攻击者对通过 HTTP 提供的服务实施长期客户端强制拒绝服务的好方法。事实上，RFC 6797 的第 14.3 节专门解决了这个问题（以及更严重的问题）：

这个 [要求 HSTS 仅通过安全连接提供服务] 背后的基本原理是，如果存在“中间人”（MITM）——无论是合法部署的代理还是非法实体——它可能会导致各种恶作剧（参见还有附录 A（“设计决策说明”）第 3 项，以及第 14.6 节（“引导 MITM 漏洞”））；例如：

• 未经授权将主机标记为已知 HSTS 主机，如果主机未通过安全传输统一提供其服务，则可能导致拒绝服务情况（另请参见第 14.5 节（“拒绝服务”））。

• 通过操作返回给 UA 的 max-age 标头字段参数值来重置主机指定为已知 HSTS 主机的生存时间。如果 max-age 返回为零，这将导致主机不再被 UA 视为已知 HSTS 主机，如果主机仅通过安全传输提供其服务，则会导致与主机的不安全连接或可能拒绝服务.

由于 HTTP 很容易被欺骗，攻击者可以指定一个 HSTS 指令来将纯 HTTP 站点视为 HTTPS 站点：然后客户端会要求 HTTPS，而服务器将无法提供它。

更严重的是，RFC 的这一部分表明，可以为主机发出 HSTS 指令的攻击者可以将主机的状态剥离为已知 HSTS 主机，从而危险地允许客户端向主机发出纯 HTTP 请求。

这可能是为了避免使用此标头引起拒绝服务攻击。

想象一个不安全的仅 HTTP 网站。现在想象一下有人能够篡改此站点发送的 HTTP 标头以添加 HSTS 标头。根据 RFC：

• UA 应该停止尝试通过 HTTP 访问站点，并尝试仅使用 HTTPS。
• 如果 UA 无法建立 HTTPS 连接，则应将其视为服务器端错误，不应给予最终用户追索权。

换句话说，最终用户将不再能够访问这个仅 HTTP 的站点，因此 DoS。