Detailed HTTP Status Code 4

302 The requested resource is now temporarily responding to the request from a different URI. 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, ignoring The method originally requested. Status codes 303 and 307 were added to clarify what response the server expects from the client.

303 The response to the current request can be found at another URI, and the client SHOULD use GET to access that resource. 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.

Transferred from Jiangsu Sanai Network