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

Question

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

在我明白问题所在之后，我的问题就解决了，但这是一个错误或预期的行为吗？如果您在POST上收到302，则不应提出异常，或者重新尝试POST到新URL。

我不想将它作为bug记录在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         响应，无论如何都对位置字段值执行GET         原始请求方法。状态代码303和307具有         已添加到希望明确清楚哪些服务器的服务器         对客户的反应是预期的。

IOW：虽然不符合RFC，但这是大多数用户代理的默认行为，大多数网络应用确实使用302而不是303来实现重定向后获取。

所以这里的requests行为显然不是一个错误，而是一个实际的设计决策。并且正如Foo Bar User已经建议的那样，您可以使用allow_redirects arg。

来改变它

Answer 2

模仿浏览器的行为，它总是在重定向上进行GET而不是POST。

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

Answer 3

根据Wikipedia请求做的是对的。如果Web服务器需要重定向并使用相同的方法，则应发送307 Temporary Redirect (since HTTP/1.1)。

  找到302

     

这是一个与之矛盾的行业惯例   标准。 HTTP / 1.0规范（RFC 1945）要求客户端   执行临时重定向（原始描述短语是   “暂时移动”），[6] 但是流行的浏览器用实现了302     303的功能见其他。因此，HTTP / 1.1添加状态   代码303和307来区分这两种行为。然而，   一些Web应用程序和框架使用302状态代码，就像它一样   是303。