HTTP POST => 302 重定向到 GET 的正确预期行为是什么？

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

在 Chrome（也可能是大多数浏览器）中，在我 POST（到希望我重定向的资源）并收到 302 重定向后，浏览器会自动在 302 位置发出 GET。这甚至是一个众所周知的模式 http://en.wikipedia.org/wiki/Post/Redirect/Get。但从我阅读规范的方式来看，这似乎表明这种情况不应该发生。

HTTP 规范说 http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3

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

小提琴手正在显示：

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

上面的部分好像是说浏览器不应该发出GET请求？我缺少什么？

1. 规范中较早的内容使本节变得无关紧要
2. 我对自动重定向的理解是错误的（并且执行 GET 的 chrome 浏览器并不是真正自动重定向）
3. 我作为用户的理解证实了这一点
4. 还有别的事吗？

规范中的下一行开始：

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

紧接着，它解释了应该如何处理 303，这正是您所看到的。

如果您问为什么服务器仍然使用 302 而不是 307（当前所有浏览器都能正确处理），那是因为旧浏览器无法处理它。如果您想知道为什么浏览器将 302 处理为 303，那是因为旧服务器期望它。确实没有办法跳出这个循环，对于 HTTP 来说，最好将 302 恢复到原来的含义，并弃用它（对于非 GET/HEAD），转而使用 307。