What is the correct behavior expected of an HTTP P

Question

What is the correct behavior expected of a POST => 302 redirect to GET?

In chrome (and likely most every browser), after I POST (to a resource that wants me to redirect) and I receive a 302 redirect, the browser automatically issues a GET on the 302 location. This is even a well known pattern. But the way I read the spec, it seems to suggest this should not happen.

The HTTP spec says

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.

And fiddler is showing:

REQUEST 1: POST URLA
RESPONSE 1: 302 redirect to URLB
REQUEST 2: GET URLB

The section above seems to say that the browser should not make the GET request? What am I missing?

1. Something earlier in the spec that makes this section irrelevant
2. My understanding of automatically redirect is wrong (and the chrome browser that did the GET wasn't really automatically redirecting)
3. My understanding of confirmed this as a user
4. Something else?

Answer 1

The very next line in the spec begins:

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.

And immediately after that, it explains how a 303 should be handled, and it's exactly what you're seeing.

---

If you're asking why servers are still using 302 instead of 307, which all current browsers will handle correctly, it's because old browsers won't handle it. If you're wondering why browsers handle 302 as 303, it's because old servers expect it. There's really no way out of that loop, and it would probably be better for HTTP to just revert 302 to mean what it used to mean, and deprecate it (for non-GET/HEAD) in favor of 307.

Answer 2

You may want to read http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-22.html#rfc.section.6.4.p.3, which tries to clarify the situation.

Answer 3

abarnert was right ! I had the same issue with Google App Engine but I found a different solution.

My issue with appengine was,I did a POST with a form to a GO formHandler at backend. But it was executed as follow.

request 1: GET /formHandler -> response 1: 302 Found

request 1: POST /formHandler -> response 1: 302 Found

request 1: GET /formHandler -> response 1: 200 Ok.

Additionaly I got

No 'Access-Control-Allow-Origin' header is present on the requested resource

Which was a CORS problem.

However the solutions turns out to be to use HTTPS instead of HTTP.

Then you will have

request : POST /formHandler -> response : 200 Ok