我在对新 API 进行一些测试后发现了这一点,并且那边的管理员说我一边做 GET,一边做 POST。启用调试后,我发现请求将执行初始 POST,然后对新的 302 URL 执行 GET。
在我了解问题所在后,我的问题现已解决,但这是错误还是预期行为?如果您在 POST 上收到 302,则不应引发异常,或者重试对新 URL 的 POST。
我不想将其作为 bug 记录在 GitHub 上,除非我确定它确实是 bug。只是想对此提供一些意见。
Thanks
根据 RFC 的规定,
如果收到 302 状态代码是为了响应除
GET 或 HEAD,用户代理不得自动重定向
请求,除非它可以被用户确认,因为这可能
更改发出请求的条件。
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3 http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3)
所以这种行为至少是不合规的 - 但 RFC 还指出:
注意:RFC 1945和RFC 2068指定不允许客户端
更改重定向请求的方法。然而,大多数
现有的用户代理实现将 302 视为 303
响应,对位置字段值执行 GET,不管
原始请求方法。状态码 303 和 307 有
已为希望明确表明哪些服务器添加
预期客户会有什么样的反应。
IOW:虽然不符合 RFC 标准,但这是大多数用户代理的默认行为,并且大多数 Web 应用程序确实使用 302 而不是 303 实现 post-redirect-get。
So requests
这里的行为显然不是一个错误,而是一个实际的设计决策。正如 Foo Bar User 已经提到的,您可以使用allow_redirects
arg.
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)