我的网站的某些部分只能通过 HTTPS 访问（而不是整个网站 - 安全性与性能之间的妥协），并且如果通过纯 HTTP 发送请求，则通过 302 重定向到安全部分的请求会强制执行 HTTPS。
问题在于所有主流浏览器，如果您在 POST 上执行 302 重定向，它将自动切换到 GET（afaik 这应该只发生在 303 上，但似乎没有人关心）。另一个问题是所有 POST 数据都丢失了。
那么，除了接受通过 HTTP 保护网站的 POST 并随后重定向或更改代码负载以确保所有用于保护网站安全部分的帖子从一开始就通过 HTTPS 之外，我还有什么选择？
【问题讨论】：
标签： http post https get http-status-code-302
你是对的，这是唯一可靠的方法。 POST 请求应该从一开始就通过 https 连接。此外，建议将导致此类 POST 的表单也通过 https 加载。通常，在您拥有 https 连接之后的第一个表单是登录表单。所有浏览器对通过 http 和 https 加载的页面应用不同的安全限制。因此，这降低了在拥有一些敏感数据的上下文中执行某些恶意脚本的风险。
【讨论】：
我认为这就是 307 的用途。 RFC2616 确实说：
如果收到 307 状态代码以响应其他请求 与 GET 或 HEAD 相比，用户代理不能自动重定向 请求，除非它可以被用户确认，因为这可能 更改发出请求的条件。
但它对 302 也说了同样的话，我们知道那里会发生什么。
不幸的是，您遇到的问题比浏览器无法按照 RFC 所说的方式处理响应代码更大，这与 HTTP 的工作方式有关。简化后，流程如下：
大概您的用户在他们的帖子中发送了一些敏感信息，这就是您希望他们使用加密的原因。但是，如果您向用户未加密的 POST（第 1 步）发送重定向响应（第 3 步），则用户已经发送了所有未加密的敏感信息。
可能是您不认为用户发送的敏感信息，而只认为您发送的响应敏感。然而，事实证明这是没有意义的。敏感信息应该只对某些个人可用，并且用于验证用户身份的信息必然是请求的一部分，这意味着您的响应现在可供任何人使用。因此，如果响应是敏感的，那么请求也是敏感的。
您似乎需要更改大量代码以确保所有安全帖子都使用 HTTPS（您可能一开始就应该这样编写它们）。您可能还想重新考虑仅在 HTTPS 上托管您的部分网站的决定。您确定您的基础架构无法处理使用所有 HTTPS 连接吗？我怀疑它可以。如果没有，可能是时候升级了。
【讨论】：