Differences between a 302 and a 307 redirect?

In version 1.0 of HTTP, there was only the 302with the meaning of "the request you just made you must make it again at this other URL". It was implicitly understood that you should use the same HTTP verb. So if you did a GET uriand received a 302, then you had to do it again GETwith the new URI. In this sense it would be equivalent to the modern 307.

But nevertheless, and contradicting the expected use, the use of 302 as a response to a form submission began to become fashionable. Thus, if a page contained an HTML form, and after filling it out the user pressed the "Submit" button, typically the browser made a request POSTto the URI specified in the form. The server could simply process the form data and return a 200 Ok, along with a results page, but this had an undesirable effect, and that is that if the user "reloaded" the results page, the POST would be done again, returning to submit the form and at the risk of a non-idempotent operation.

To avoid this it became customary to respond to that POST with a 302, so that the browser would then do a GETto that new URL which would display the results page. Thus, a reload of that page would do a new GETinstead of repeating the POST.

So the code 302had become ambiguous. Either it had its originally intended meaning that the resource had been moved temporarily and the verb had to be repeated over the new URL, or the new "de facto" adopted meaning that the 302 response to a POST should involve the use of a GET to get the results page.

To undo that ambiguity, HTTP version 1.1 introduced two new status codes:

• 303: This would be the meaning "do a GET to this URI" after having previously done a POST.
• 307: This would be the original meaning of 302: "repeat the same verb on this other URI".

By the way, in HTTP/1.1 302 should no longer be used, it has been replaced by 303/307 as I just explained. But there are still sites that continue to use it in response to a POST.