Today, I plan to take a good look at the status codes 301, 302, 303, 307, and 308, and I will test some examples.
Explanation of Status Codes
We all know that redirection is related to these status codes. Let's take a look at the explanations of these HTTP status codes (from Wikipedia)
301 Moved Permanently
The requested resource has been permanently moved to the new location, and any future references to this resource SHOULD use one of the several URIs returned in this response. If possible, clients with link editing capabilities should automatically modify the requested address to the address returned from the server. Unless otherwise specified, this response is also cacheable. The new permanent URI SHOULD be returned in the Location field of the response. Unless this is a HEAD request, the entity of the response SHOULD contain a hyperlink to the new URI and a short description. If this is not a GET or HEAD request, the browser therefore prohibits automatic redirection unless confirmed by the user, as the conditions of the request may change accordingly. Note: For some browsers using the HTTP/1.0 protocol, when they send a POST request and get a 301 response, the subsequent redirect request will become a GET method.
302 Found
Ask the client to perform a temporary redirect (original description phrase was "Moved Temporarily"). Since such redirects are temporary, the client SHOULD continue to send future requests to the original address. This response is cacheable only if specified in Cache-Control or Expires. The new temporary URI SHOULD be returned in the Location field of the response. Unless this is a HEAD request, the entity of the response SHOULD contain a hyperlink to the new URI and a short description. If this is not a GET or HEAD request, the browser prohibits automatic redirection unless confirmed by the user, as the conditions of the request may change accordingly. Note: Although the RFC 1945 and RFC 2068 specifications do not allow the client to change the method of the request when redirecting, many existing browsers treat the 302 response as a 303 response and use GET to access the URI specified in the Location without ignoring The method originally requested. So status codes 303 and 307 were added to make it clear what the server expects the client to do.
303 See Other
The response corresponding to the current request can be found at another URI, and when a response is received in response to a POST (or PUT/DELETE), the client SHOULD assume that the server has received the data, and SHOULD issue a redirect using a separate GET message. This method exists primarily to allow script-activated POST request output to be redirected to a new resource. This new URI is not an alternate reference to the original resource. Also, 303 responses MUST NOT be cached. Of course, the second request (redirect) may be cached. The new URI should be returned in the Location field of the response. Unless this is a HEAD request, the entity of the response SHOULD contain a hyperlink to the new URI and a short description. Note: Many pre-HTTP/1.1 browsers do not properly understand the 303 status. If interaction with these browsers is a concern, a 302 status code should do the trick, as most browsers handle 302 responses exactly the way the above specification requires clients to handle 303 responses.
307 Temporary Redirect
In this case, the request SHOULD be repeated with another URI, but subsequent requests SHOULD still use the original URI. Contrary to 302, when the original request is reissued, changing the request method is not allowed. For example, the POST request should be repeated with another POST request
308 Permanent Redirect
The request and all future requests SHOULD be repeated using another URI. 307 and 308 repeat the behavior of 302 and 301, but do not allow HTTP method changes. For example, submitting a form to a permanently redirected resource might go smoothly.
pending upgrade. . .