python-requests changes a POST to a GET when receiving an HTTP 302. Is this expected behavior?

Question

I discovered this after some testing on a new API and the admin on that side said I'm doing GETs while I'm doing POSTs on my side. After enabling debugging, I found that requests will do the initial POST and then do a GET on the new 302 URL.

My problem is fixed now after I understood what the problem was, but is this a bug or expected behavior? If you receive a 302 on a POST, should you not raise an exception, or retry the POST to the new URL.

I don't want to log it on GitHub as a bug, unless I'm sure that it is one. Just want some input on this.

Thanks

Answer 1

According to the RFC,

If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

(http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3)

So this behaviour is at least not compliant - BUT the RFC also states that:

Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.

IOW: while not RFC compliant, this is the default behaviour for most user-agents, and most web apps do indeed implement post-redirect-get with a 302 instead of a 303.

So requests behaviour here is obviously not a bug, but a practical design decision. And as Foo Bar User already mentinned, you can alter this using the allow_redirects arg.