服务器是否可以以“纯” HTTP 模式发送标准标头，以向浏览器提示 HTTPS 可用且推荐？
我已经使用了 HSTS 机制来告诉浏览器不要切换回 HTTP，但它们只有在已经处于安全连接时才有效。目前我使用 Apache 中的 Rewrite 功能让客户端使用 HTTPS，但我希望有一个不那么强制的替代方案。
答案1
为了回答所问的具体问题，实际上有一个提议几乎就是你想要的，即HTTP 替代服务拟议标准来自 HTTP 工作组。该草案目前的形式是在几个月前，即 2016 年 5 月 3 日发布的，当前的互联网草案将于 2016 年 11 月 4 日到期。
考虑到它还很新，我预计 UA 支持充其量也只是极其不稳定。（马克·诺丁汉声称该支持已添加到 Firefox 和 Chrome，但没有给出任何版本号。）此外，它是供 UA 解释的，不一定供用户做出选择。
从更一般的层面来说，我认为你必须考虑一下为什么你不想“强制”UA 使用 HTTPS。是因为 HTTPS 的性能成本吗？（提示：这在当今完全可以忽略不计，特别是如果您还能够实现 HTTP/2。）是因为某些客户端可能无法使用加密吗？（提示：如果这对您来说真的是一个很大的用例，那么请支持未加密的 TLS 密码套件。我不建议这样做，但从技术上讲，这在技术上是可行的，就像将您的汽车开下悬崖一样。至少这样，您应该获得 HTTPS 的真实性保证，但不是保密性。）是因为您的客户端不支持 SNI 吗？（然后考虑为该重要网站分配一个 IP 地址，以支持卡在网络浏览器过时了 5-10 年。
强制使用 HTTPS几个非常实际的好处即使您的网站上没有任何“秘密”，或者您并不关心 Google 排名的小幅提升。
您始终可以使用 HTTP307响应暂时地如果您愿意，可以将客户端从 HTTP 站点重定向到 HTTPS 站点，但将临时重定向到 HTTPS 与 HSTS 结合起来有点不合常理。
鉴于你已经在使用 HSTS，我建议你只需设置一个 HTTP301从 HTTP 虚拟主机永久重定向到 HTTPS 虚拟主机，然后结束这一天。如今，没有理由不这么做。
答案2
听起来这个问题实际上是在问——浏览器是否会使用一个标头来向用户传达 https 可用，并且他们应该决定采取行动来使用它，出于这个、那个和其他原因。
答案是否定的。这不是应用程序要问用户的问题，相对于应用程序向用户提出构成应用程序目的的其他问题和决定而言。
应用程序有责任确保与用户交互的安全性、完整性和保密性，而不是向用户问一些毫无意义的问题——你是否希望你们的交互是保密的，等等。当然希望如此。
应用程序必须使用与浏览器建立的信任边界环境中可用的自动化机制，以确保这些属性能够表征交互，而无需用户采取行动。
因此，如果用户请求 http，则使用重写规则提供 http 301 响应代码以将浏览器指向 https 是正确的做法。
请注意，Google Chrome 本身会开始发出信号，表示仅使用 http 的网站是不安全的，首先是那些有登录名的网站 - 比如 StackOverflow 家族。
所以不要担心用户体验或用户决策部分。使用 http 301 并使用其他标头（如 hsts 和 x-frame-options）和内容安全策略并确保用户安全。