The story of HTTP status Codes 302, 303, and 307

In the 3rd chapter of the HTTP authoritative guide, when explaining the 30X status code, it is not clear why there should be 302, 303, 307, and their relationship, a "problem in HTTP/1/1" Let me confused, inexplicably, and the fifth chapter in the redirect response, did not say that now very common 302 , instead of 303 and 307 that I've never met. Very confusing, for these 3 status codes, Wiki and RFC documents are detailed, the following I think in my mind to embellish the description again.

A, status code--302                                      ,         &NB Sp                          ,         &NB Sp                          ,         &NB Sp                          ,         &NB Sp      

    RFC1945 (http://tools.ietf.org/html/rfc1945#page-34), That is, HTTP1.0, when introducing 302, said that if the client sends a POST request and receives a 302 status code from the server, it cannot automatically send a duplicate request to the new URI and must confirm with the user whether it should be re-sent, because the environment may have changed since the second post (well, the Post method is not idempotent), post The operation will not meet the user's expectations. However, many browsers (the user agent I describe as a browser for ease of introduction) will turn the POST request into a GET request in this case.     RFC2616 (http://tools.ietf.org/html/rfc2616#section-10.3.3), HTTP1.1, when introducing 302, says that if a client makes a non-get, head request, If you receive a 302 status code on the server, you cannot automatically send a duplicate request to the new URI unless you are confirmed by the user. (again-,-) However, many browsers treat 302 as 303 (note that 303 is HTTP1.1 just add in, in fact, from HTTP1.0 Evolution to HTTP1.1, browser nothing moved), they get to the HTTP response Message header location field information, and initiate a GET request.

II, status codes--303 and 307                                          ,         &NB Sp                          ,         &NB Sp                          ,         &NB Sp                          &NBSP

    from the above introduction can know, HTTP1.1 and HTTP1.0 302 status code meaning is the same, the browser to its processing is the same. The redirection of the Post method becomes get when the user is not queried, and the problem that does not conform to the document specification persists. In practice before and after the document, HTTP1.1 the post-get behavior into the RFC document: HTTP1.1 New 303 and 307 status codes are added. The response to the 303 status code in the     documentation is now the browser's handling of the 302 status code as mentioned above: Post redirection is get.     The 307 status code in the HTTP1.1 document is equivalent to the 302 status code in the HTTP1.0 document, and when the client's post request receives a service-side 307 status Code response, it needs to ask the user if the Post method should be initiated on the new URI, that is, 307 does not convert the post to get.     Search from the Web "303: For a POST request, it indicates that the request has been processed, and the client can then use the Get method to request the URI in the location. 307: For a POST request, the request has not been processed and the client should re-initiate the POST request to the URI in the location. ", from the above introduction can understand that this statement is hypothetical, the document did not say, and the industry is unified so deal with, it is not good to say that I did not catch 307 and 303 of the package.     documentation also says, To be compatible with many HTTP1.1 browsers, the server will choose to replace the 302 status code when it needs to issue a 303 status code, whereas for 307 processing, it is necessary to include information in the response entity so that the user who cannot process the 307 status code has the ability to initiate duplicate requests in the new URI, that is, to present the redirected page to the user. Let the user go to the Point redirect Uri Link (URI is now basically URL).

Iii. Summary

303 and 307 are HTTP1.1 new server response document status code, they are HTTP1.0 in the 302 status code refinement, mainly used in the response to the non-get, head method. Documentation stipulates: The browser to the 303 status code processing with the original browser to the HTTP1.0 302 status Code processing method, the browser to the 307 status code processing and the original HTTP1.0 document in the same description of 302. The existence of 303 and 307 is, in the final analysis, caused by the non-idempotent properties of the Post method. In HTTP1.1, 302 is theoretically to be discarded, it is refined to 303 and 307, but in order to be compatible, it is still heavily used in the industry, and 303 and 307 status codes I have not met (no use of the scene, and have not caught such a response message). Why does the industry use 303 and 307 less? For the Get and head methods, 307 is not necessary, with 302 or 303 to meet the requirements, 307 is only useful in the redirection of the Post method. So I guess there are two reasons why they are rare: 1, the use of post method redirection is too few, so that 307 status code is not available, 2, the Get method is often required to use the redirect, but the use of 302 status code can also operate correctly, Consider the minimal compatibility issues (now the browser may not support HTTP1.1!).   ), there is no need to use 303. Transferred from: http://www.cnblogs.com/cswuyg/p/3871976.html Reference: 1, http 302 wiki http://en.wikipedia.org/wiki/HTTP_3022, RFC1945 http://tools.ietf.org/html/rfc1945#page-343, RFC2616 http://tools.ietf.org/html/rfc2616#section-10.3.3

The story of HTTP status Codes 302, 303, and 307