如何解决POST在302重定向时更改为GET？
我的网站的某些部分只能通过HTTPS访问（不是整个网站 - 安全与性能妥协），并且如果通过普通HTTP发送HTTPS，则会对安全部分的请求重定向302。
问题出在所有主流浏览器上，如果你在POST上做302重定向，它会自动切换到GET（afaik这应该只发生在303上，但似乎没有人关心）。 另外的问题是所有的POST数据都会丢失。
那么除了接受POST来确保HTTP上的站点安全以及事后重定向或更改代码负载以确保所有安全部分网站的安全措施从一开始就覆盖HTTPS之外，我还有什么选择？
你是对的，这是唯一可靠的方法。 POST请求应该从一开始就通过https连接。 此外，建议通过https加载导致这种POST的表单。 通常，在https连接之后的第一个表单是登录表单。 所有浏览器对通过http和https加载的页面应用不同的安全限制。 因此，这降低了在拥有一些合理数据的情况下执行一些恶意脚本的风险。
我认为这就是307的目的。 RFC2616确实说：
如果接收到307状态码以回应GET或HEAD以外的请求，则用户代理绝不能自动重定向请求，除非用户可以确认它，因为这可能会改变发出请求的条件。
但它说的是关于302的同样的事情，我们知道那里发生了什么。
不幸的是，与浏览器没有处理响应代码的方式相比，RFC的说法和HTTP的工作方式有关，您遇到的问题更大。 简化的过程如下所示：
推测你的用户在他们的帖子中发送了一些敏感信息，这就是你希望他们使用加密的原因。 但是，如果您向用户的未加密POST（步骤1）发送重定向响应（步骤3），则用户已经将所有敏感信息都未加密发送出去。
这可能是因为你没有考虑用户发送的敏感信息，只考虑你发送的敏感信息。 但是，事实证明这是没有道理的。 敏感信息应仅适用于某些个人，并且用于验证用户的信息必然是请求的一部分，这意味着您的回复现在可供任何人使用。 所以，如果响应敏感，请求也很敏感。
看来你会想要改变很多代码来确保所有安全的帖子都使用HTTPS（你可能应该首先将它们写成这样）。 您可能还想重新考虑您的决定，即仅在HTTPS上托管您的一些网站。 您确定您的基础架构无法处理使用所有HTTPS连接吗？ 我怀疑它可以。 如果不是，那么可能是升级的时候了。
链接地址: http://www.djcxy.com/p/45415.html上一篇: How to work around POST being changed to GET on 302 redirect?