符合规范的浏览器会忽略通过 HTTP 发送的 HSTS 标头 - 这是为了防止中间人通过在浏览器中设置 HSTS 规则而导致访问者无法访问非 HTTPS 网站。（参见RFC 6797）

因此，尽管技术上不正确，您可以安全地向所有用户提供 HSTS 标头，并通过 HTTP 和 HTTPS 提供相同的页面，并且故意不从不安全的页面重定向到安全的页面。

这将导致访问您的 HTTPS 版本的访问者将在未来访问时被迫返回（至少在标头的持续时间内），而故意访问您的 HTTP 版本的访问者将继续使用该版本。如果他们在任何时候跟随指向 HTTPS 版本的链接，他们将在未来被迫使用 HTTPS。

至于它是否有意义，这取决于您的目标和访问者 - 您是否有很多来自损坏代理的访问者？您是否提供了可能在某些页面上定罪的信息？

就个人而言，我只提供安全版本，并从不安全版本强制重定向，特别是因为搜索引擎似乎正在转向更喜欢安全网站。

通过 HTTP 访问站点时，HSTS 标头不起作用。

HSTS 的目标是强制浏览器通过 HTTPS 加载站点，选择通过 HTTP 查看它是违反直觉的。

我想知道在通过 HTTPS 和 HTTP 提供服务的站点上启用 HSTS 是否有意义。

我不完全确定 HSTS，但我认为是的。

（这个想法本身是合理的。它类似于“机会加密”的想法：通过对至少某些连接使用至少一定数量的加密来使攻击者更加努力。）

RFC 的摘要是这样说的：

该规范定义了一种机制，使网站能够声明自己只能通过安全连接访问和/或让用户能够指导他们的用户代理仅通过安全连接与给定站点进行交互。

句子的“和/或”位在这里似乎很重要。

所以你可以通过 HSTS 做的就是声明如下内容：这个站点一直是 HTTPS。即使您的防火墙阻止了与端口 80的所有连接，此站点也可以为您工作。事后考虑：如果这里有一个普通的 HTTP 链接，那么这是一个错误，请悄悄地将其升级到 HTTPS。

而这个静默升级异或失败位将使您免于他们在此处给出的场景：（第 2.3.1.3 节）

即使网站的开发人员仔细检查他们的登录页面是否存在“混合内容”，整个网站任何地方的单个不安全嵌入也会危及他们登录页面的安全性，因为攻击者可以通过注入代码（例如, 一个脚本) 到另一个加载不安全的站点页面。

虽然服务器应该将客户端重定向到 HTTPS（第 7.2 节）：

如果 HSTS 主机通过非安全传输接收到 HTTP 请求消息，它应该发送包含指示永久重定向的状态代码的 HTTP 响应消息，

...这是应该的，而不是必须的。

因此，总而言之：是的，您要问的应该是 HSTS 的可能和合法使用。

另一件事：如果您希望支持可能同时使用站点的 HTTPS 版本（例如在家中）和站点的普通 HTTP 版本（例如从他们的办公室 WIFI）的笔记本电脑用户，那么您将必须设置 HSTS 超时足够低。（也许几分钟。）