python - python-requests 在收到 HTTP 302 时将 POST 更改为 GET。这是预期的行为吗？

Question

在对新 API 进行一些测试后，我发现了这一点，并且那边的管理员说我正在做 GET，而我正在做 POST。启用调试后，我发现请求将执行初始 POST，然后对新的 302 URL 执行 GET。

在我了解问题所在后，我的问题现在已解决，但这是错误还是预期行为？如果您在 POST 上收到 302，您应该不引发异常，还是重试 POST 到新 URL。

我不想将它作为一个错误记录在 GitHub 上，除非我确定它是一个错误。只是想对此有所了解。

谢谢

Answer 1

根据 RFC，

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

（http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3）

所以这种行为至少是不合规的——但 RFC 还指出：

注意：RFC 1945 和 RFC 2068 指定不允许客户端更改重定向请求的方法。然而，大多数现有的用户代理实现将 302 视为 303 响应，无论原始请求方法如何，都对 Location 字段值执行 GET。状态码 303 和 307 已被添加用于希望明确明确期望客户端做出何种反应的服务器。

IOW：虽然不符合 RFC，但这是大多数用户代理的默认行为，并且大多数 Web 应用程序确实使用 302 而不是 303 实现了 post-redirect-get。

所以requests这里的行为显然不是一个错误，而是一个实际的设计决策。并且由于 Foo Bar User 已经提及，您可以使用allow_redirectsarg 更改它。

Answer 2

这模仿了浏览器的行为，浏览器总是在重定向时执行 GET，而不是 POST。

维基百科对这种行为有解释：在原始标准下，浏览器应该使用 POST 进行重定向，但它们都使用 GET 来实现它。引入了状态码 303 和 307 来澄清这一点，其中 303 是当前（GET）行为，307 是最初预期的行为（POST），但这些在实践中很少使用。

Answer 3

根据维基百科，请求所做的是正确的。如果 Web 服务器想要重定向并使用相同的方法，它应该发送307 Temporary Redirect (since HTTP/1.1)。

302 找到

这是行业实践与标准相矛盾的一个例子。HTTP/1.0 规范 (RFC 1945) 要求客户端执行临时重定向（最初的描述短语是“临时移动”），[6]但流行的浏览器使用 303 See Other的功能实现了 302 。因此，HTTP/1.1 增加了状态码 303 和 307 来区分这两种行为。但是，一些 Web 应用程序和框架使用 302 状态代码，就好像它是 303。