9

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

Dax
  • 369
  • 2
  • 7

3 Answers3

8

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.

bruno desthuilliers
  • 75,974
  • 6
  • 88
  • 118
  • Thank you for the detailed response. I'm already using the correct URL, so there is no issue for me. I was just wondering about this strange behavior. – Dax Oct 17 '13 at 09:02
  • @Dax haha, wikipedia says 'This is an example of industry practice contradicting the standard.' – Leonardo.Z Oct 17 '13 at 09:08
2

That mimics the behaviour of browsers, which will always do a GET on a redirect, not a POST.

Wikipedia has an explanation of this behaviour: under the original standard, browsers were supposed to redirect with a POST, but they all implemented it with a GET. Status codes 303 and 307 were introduced to clarify this, with 303 as the current (GET) behaviour and 307 as the originally intended one (POST), but these are rarely used in practice.

Daniel Roseman
  • 588,541
  • 66
  • 880
  • 895
0

According to Wikipedia what requests did is right. If a web server wants a redirect and use the same method , it should send 307 Temporary Redirect (since HTTP/1.1).

302 Found

This is an example of industry practice contradicting the standard. The HTTP/1.0 specification (RFC 1945) required the client to perform a temporary redirect (the original describing phrase was "Moved Temporarily"),[6] but popular browsers implemented 302 with the functionality of a 303 See Other. Therefore, HTTP/1.1 added status codes 303 and 307 to distinguish between the two behaviours. However, some Web applications and frameworks use the 302 status code as if it were the 303.

Leonardo.Z
  • 9,425
  • 3
  • 35
  • 38