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