问题描述
POST => 302 重定向到 GET 的正确行为是什么?
What is the correct behavior expected of a POST => 302 redirect to GET?
在 chrome(可能是大多数浏览器)中，在我 POST(到希望我重定向的资源)并收到 302 重定向后，浏览器会自动在 302 位置发出 GET.这甚至是一个众所周知的模式.但是我阅读规范的方式似乎表明这不应该发生.
In chrome (and likely most every browser), after I POST (to a resource that wants me to redirect) and I receive a 302 redirect, the browser automatically issues a GET on the 302 location. This is even a well known pattern. But the way I read the spec, it seems to suggest this should not happen.
如果收到 302 状态代码以响应请求，而不是GET 或 HEAD，用户代理不得自动重定向请求除非用户可以确认，因为这可能更改发出请求的条件.
小提琴手正在展示:
REQUEST 1: POST URLA
RESPONSE 1: 302 redirect to URLB
REQUEST 2: GET URLB
上面这一段好像是说浏览器不应该做GET请求吧?我错过了什么?
The section above seems to say that the browser should not make the GET request? What am I missing?
- 规范中较早的部分使本节不相关
- 我对自动重定向的理解是错误的(执行 GET 的 chrome 浏览器并没有真正自动重定向)
- 我作为用户确认了这一点
- 还有别的吗?
推荐答案
规范中的下一行开始:
注意:RFC 1945 和 RFC 2068 指定不允许客户端更改重定向请求的方法.然而，大多数现有的用户代理实现将 302 视为 303响应，对 Location 字段值执行 GET，不管原始请求方法.状态码 303 和 307 有为希望明确说明哪些服务器添加了期待客户的反应.
紧接着，它解释了应该如何处理 303，这正是您所看到的.
And immediately after that, it explains how a 303 should be handled, and it's exactly what you're seeing.
如果你问为什么服务器仍然使用 302 而不是 307，所有当前浏览器都会正确处理，这是因为旧浏览器不会处理它.如果您想知道为什么浏览器将 302 处理为 303，那是因为旧服务器期望它.确实没有办法摆脱这个循环，对于 HTTP 来说，最好将 302 恢复为它过去的意思，并弃用它(对于非 GET/HEAD)以支持 307.
If you're asking why servers are still using 302 instead of 307, which all current browsers will handle correctly, it's because old browsers won't handle it. If you're wondering why browsers handle 302 as 303, it's because old servers expect it. There's really no way out of that loop, and it would probably be better for HTTP to just revert 302 to mean what it used to mean, and deprecate it (for non-GET/HEAD) in favor of 307.
这篇关于HTTP POST => 预期的正确行为是什么?302重定向到GET?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！