When HTTP1.0 introduced 302, it said that if the client sends a POST request and receives a 302 status code from the server, it cannot automatically send a repeat request to the new URI, and must confirm with the user whether it should be re-sent, because the second time At the time of POST, the environment may have changed (well, the POST method is not idempotent), and the POST operation will not meet the user's expectations. However, many browsers (user agent I describe as browsers for convenience) will turn POST requests into GET requests in this case.
When HTTP1.1 introduced 302, it said that if the client sends a non-GET, HEAD request and receives a 302 status code from the server, it cannot automatically send a repeat request to the new URI unless it is confirmed by the user. (again -,-) However, many browsers treat 302 as 303 (note that 303 was only added in HTTP1.1, in fact, from HTTP1.0 to HTTP1.1, the browser did not move anything ), they obtain the Location field information in the header of the HTTP response message, and initiate a GET request.
The meaning of the 302 status code of HTTP1.1 and HTTP1.0 is the same, and the browser handles it in the same way. The redirection of the POST method becomes a GET without asking the user, and this non-documentation problem still exists. Practice comes first and documentation comes after. HTTP1.1 incorporates this behavior of POST into GET into the RFC document: HTTP1.1 adds 303 and 307 status codes.
303 and 307 are the status codes of the newly added server response documents in HTTP 1.1. They are refinements of the 302 status codes in HTTP 1.0, and are mainly used for responses to non-GET and HEAD methods. The document stipulates that the browser handles the 303 status code in the same way as the original browser handles the 302 status code of HTTP1.0; the browser handles the 307 status code in the same way as the description of 302 in the original HTTP1.0 document.