Question

POST =＆gt;的正确行为是什么？ 302重定向到GET？

在chrome（可能是大多数每个浏览器）中，在POST（对于希望我重定向的资源）并且我收到302重定向之后，浏览器会自动在302位置发出GET。这甚至是well known pattern。但是我阅读规范的方式似乎表明这不应该发生。

如果收到302状态代码以响应除以外的请求 GET或HEAD，用户代理不得自动重定向 请求，除非用户可以确认，因为这可能改变发出请求的条件。

小提琴手正在展示：

REQUEST 1: POST URLA
RESPONSE 1: 302 redirect to URLB
REQUEST 2: GET URLB

上面的部分似乎说浏览器不应该发出GET请求？我错过了什么？

规范中较早的内容使此部分无关紧要
我对自动重定向的理解是错误的（并且执行GET的Chrome浏览器并没有真正自动重定向）
我的理解确认为用户
别的什么？

Answer 1

规范中的下一行开始：

注意：RFC 1945和RFC 2068指定不允许客户端更改重定向请求的方法。但是，大多数现有的用户代理实现将302视为303 响应，无论如何都对位置字段值执行GET 原始请求方法。状态代码303和307具有已添加到希望明确清楚哪些服务器的服务器对客户的反应是预期的。

在此之后，它解释了如何处理303，这正是你所看到的。

如果您问为什么服务器仍在使用302而不是307，这是当前所有浏览器都能正确处理的，那是因为旧浏览器无法处理它。如果你想知道为什么浏览器将302作为303处理，那是因为旧服务器期望它。实际上没有办法摆脱那个循环，并且HTTP可能更好地恢复302意味着它的意思，并且弃用它（对于非GET / HEAD）而支持307。

Answer 2

您可能需要阅读http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-22.html#rfc.section.6.4.p.3，其中会尝试澄清情况。

Answer 3

abarnert是对的！我在使用Google App Engine时遇到了同样的问题，但我发现了一个不同的解决方案。

我对appengine的问题是，我在后端用GO formHandler做了一个带有表单的POST。但它执行如下。

请求1：GET / formHandler - ＆gt;回复1：302发现

请求1：POST / formHandler - ＆gt;回复1：302发现

请求1：GET / formHandler - ＆gt;回复1：200好。

另外我得到了

否＆＃39;访问控制 - 允许 - 来源＆＃39;标头出现在请求的资源上

这是一个CORS问题。

然而，解决方案原来是使用HTTP S 而不是HTTP。

然后你会有

请求：POST / formHandler - ＆gt;回复：200好

HTTP POST =＆gt;所期望的正确行为是什么？ 302重定向到GET？

3 个答案: