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

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

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.