http://www.example.com
http://www.example.com/

从浏览器和 HTTP 协议的角度来看，这些实际上没有区别。URL 由（除其他外）协议 ( http://)、主机名 ( www.example.com) 和路径组成。空路径是不可能的，显示的两个 URL 都使用 path /。因此，这些 URL 之间没有实际的重定向，因为它们已经是等效的。

有关这方面的更多信息，请参阅 HTTP 标准，特别是RFC 7321 第 5.3.1 节： “如果目标 URI 的路径组件为空，则客户端必须发送“/”作为请求目标的原始形式中的路径。” . 请注意，这只适用于http://example.comvs. http://example.com/，即空路径 vs. /。使用/foovs.的路径/foo/是不同的，因为这些实际上会导致不同的请求。

此外，用户最终目的地是 HTTPS，所以我认为它应该足够安全。

由于初始请求和响应仍然是通过纯 HTTP 完成的，因此它们不受中间人操纵的保护。例如，可以修改响应或注入新响应以将客户端定向到不同的最终 URL。这实际上发生了，请参见例如Internet Provider Redirects Users in Turkey to Spyware: Report。

换句话说：每个明文重定向都太过分了。为了减少这种攻击向量，进一步使用HSTS。

http 和 https 之间没有“安全”重定向。第一步是不安全的（http），可以相对容易地受到损害。

考虑到这一点，如果不安全步骤是一个或多个，从安全角度来看并不重要。

什么可以用来改善这种情况：

• HSTS：只有第一个请求是 http。后续请求将始终直接转到 https 浏览器端。
• 宣传 https 链接。如果不希望用户在他们的浏览器中键入它，而是点击链接，那就太好了。

您根本不应该提供纯文本 HTTP 服务，这样就不会有重定向问题。现代浏览器无论如何都会尝试 HTTPS 连接。例如，如果您输入example.com，现代浏览器会在 http 之前尝试 https。即使您尝试，如果连接被拒绝（即关闭端口）http://example.com，体面的浏览器（我认为的所有现代浏览器）也会尝试。httpshttp

另一件需要记住的重要事情：您在网站内提供的任何内部链接或引用最好是相对的，但如果它们出于任何原因是绝对的，那么它们应该是https-only - 浏览器通常会拒绝从安全内容中到同一域的不安全重定向。

推论：在保护您的服务的防火墙上，确保端口 http (80) 的规则是 REJECT，而不是DROP。后者会导致连接超时，这不仅会提供糟糕的用户体验，而且浏览器在 http 超时后重试 https 的情况也不常见。为了防止参与反射流量 DOS 攻击，请确保端口 80（以及所有其他拒绝连接而不是丢弃它们的端口）的传出速率受到每个远程 IP 地址的限制。不过，通常情况下，您会让 Cloudflare 或类似的东西担心这一点。

它的安全性不亚于直接从 http 到 https 的重定向。从技术上讲，攻击者可能有两次拦截重定向的机会 - 但如果有人正在攻击您的网络，通常是全有或全无。他们要么拦截两个重定向（就像拦截一样糟糕），要么都不拦截。