从 HTTP 重定向到 HTTPS 并不是一件坏事。不好的是依赖它，就好像它是一个安全功能一样。

这种重定向是一座灯塔，旨在让在风暴中迷失在海上的船只能够了解它们的位置，并且如果幸运的话，可以让它们有更好的机会到达避风港。没有人声称灯塔会使风暴消失；他们只是提高了恶劣条件下幸福结局的可能性。

关于从 HTTP 到 HTTPS 的自动重定向唯一可以说的坏事是它滋生了自满情绪。如果用户犯了错误，例如试图以 HTTP 而不是 HTTPS 访问网站，自动重定向允许他坚持他的错误方式，隐藏他不适当的 URL 使他暴露于互联网居民的报复的事实，有些人相当有时主动作恶。禁用此重定向可能被解释为更具教学性。但是，这种观点有些不切实际；大多数网站所有者都无法教育用户。他们想要的是抓住潜在客户的注意力. 如果您开始使访问您的网站变得更加困难，那么它们就会消失；他们不会受到丝毫的教育，生意也会受到影响。

“杀不死我们的会让我们更强大。” 来自一个过半疯狂的哲学家的朗朗上口的短语；但不一定适用于大众作为教育政策。通过试图杀死他们使人们变得更强大的问题在于，有时你会成功——我的意思是杀死他们。

正如spuratic 先生解释的那样，为了真正让事情变得更好，浏览器应该默认使用HTTPS；理想情况下，整个 Web 将是 HTTPS-only：如果浏览器首先尝试 HTTPS，但在出现错误时回退到 HTTP，那么主动攻击者可以模拟失败并强制回退。DNSSEC 与适当的 SRV 记录相结合可以以安全的方式宣传给定的服务器应该仅与 HTTPS 一起使用，但这只有在......它可以在任何地方工作时才能可靠地工作（与 IPv6 相同的引导问题）。

同时，即使羊完全不知道在夜间乡村漫游的野兽，重定向也会将流浪羊带到马厩。这通常被认为比试图教羊不要迷路更有效的方法。

问题是双重的：

• 今天，网站（或其他服务）无法明确声明（例如通过经过身份验证的 DNS）它只提供HTTPS（安全）服务，而不提供HTTP。服务记录 ( _srv) 不起作用（尽管该问题没有被完全忽略，请参阅此处的 https 条目），并且 HSTS 有一个不可避免的问题。从 HTTP 到 HTTPS 的初始重定向在今天是必要的。HTTPS Everywhere（首先尝试 HTTPS）在技术上是一种更好的解决方案，尽管任何需要用户选择加入和/或非平凡程度的用户能力的解决方案都受到严重限制。ssls带将持续到此问题得到解决。（DNSSEC 也有类似的引导问题，直到 99% 的域都被签名，并且 100% 的解析器都期望这一点。DNS 通常是房间里的大象。）
• 除了（有效）未经身份验证的重定向问题，无条件透明重定向到 HTTPS 可能会隐藏潜在问题（例如，当使用 HTTPS 终止负载平衡器/反向代理时，应用程序生成具有错误协议：// 前缀的绝对 URL ）。像“安全”这样的 Cookie 安全属性是创可贴的。严格保持HTTPS 会话的设施HTTPS 是不完善的。

通过一个思想实验：想象一个 SSH 客户端是否有帮助且默默地先尝试了 telnet。如果 SSH 连接可以在中途几乎无声地变成 telnet 连接怎么办？这个客户在安全意识中的受欢迎程度如何？如果它总是“正常工作”（并且有插件/主题等），它在安全不可知论者中会有多受欢迎？这与现代浏览器有何不同^{† ？}

_{^†除了不可能的内存需求、无端的 UI 不一致和不断的后台更新；这些应该不言而喻。}

将http重定向到https不好吗？

HTTPS 很好，但依靠通过未经身份验证、未加密和无法验证的传输进行重定向表明通常与国家彩票客户相关的乐观程度。

将 HTTP 重定向到 HTTPS 是一个糟糕的主意[...]？

不完全正确。始终观察 HTTPS UI 指示器的用户有合理的理由相信他在正确的位置，并具有一定的保护措施。我怀疑这不是模态用户。

糟糕的是管理员天真地断定启用 HTTPS 以某种方式解决了所有常见的安全问题。

令人讨厌的身份验证、完整性、机密性三位一体真的是全有或全无......

TL;DR：这不是一个糟糕的想法，它几乎肯定不能解决人们希望它解决的问题，但也没有可行的替代方案可以解决这些问题。简单地把它强加给你的用户可能只会对他们中的一小部分产生影响；开展活动并教育您的用户将使您走得更远。