http的302，303和307

http的302，303和307

在HTTP当中有些用于表示重定向的状态码，范围在3XX。

这里主要说一下302，303和307的区别。

这三个状态码在平时都表现为重定向，服务器返回一个新的资源的地址，客户端去这个新的地址去获取资源。但是它们之间还是有些细微的区别的。我们通过仔细阅读RFC可以发现：

1.302 Found。302返回码指示资源临时在另一个位置，该位置通过Location指定。如果302响应对应的请求方法不是GET或者HEAD，那么客户端在获得用户许可之前是不能自动进行重定向的，因为这有可能会改变请求的条件。在RFC1045和RFC2068中指明客户端在响应重定向时是不可以改变请求的方法的。但是在多数实现中，总是使用GET方法来获取新位置的资源。这样就将其实现为303的要求了。

2.303 See Other。请求的资源可以在另一个URI处找到，客户端必须使用GET方法来获取新位置的资源。不能缓存303响应，但是可以缓存第二次请求的响应。This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource.很多客户端识别303状态码，302状态码的实现其实就是对303状态码的响应。

3.307 Temporary Redirect。同303一样，对于非GET和HEAD请求不能自动重定向。与302的区别是： The Web client issues a request to the new location of the resource using the same request method it used in the current transaction (rather than always using GET).也就是说307相较于302来说，后续请求资源的方法是使用与当前交互相同的方法而不是全部使用GET。

由此可见：303和307的出现是明确了302中的混乱状态。建议以后使用303和307，302在以后将会被淘汰掉。

301 永久重定向,告诉客户端以后应从新地址访问.

302 作为HTTP1.0的标准,以前叫做Moved Temporarily ,现在叫Found. 现在使用只是为了兼容性的处理,包括PHP的默认Location重定向用的也是302.

但是HTTP 1.1 有303 和307作为详细的补充,其实是对302的细化

303：对于POST请求，它表示请求已经被处理，客户端可以接着使用GET方法去请求Location里的URI。

307：对于POST请求，表示请求还没有被处理，客户端应该向Location里的URI重新发起POST请求。

实际测试:

测试内容:

写一个测试的test.html代码,发起post请求到test.php页面中

test.php页面分别给出3种重定向处理,都跳到test2.php

test2.php打印出post的结果

(至于怎么写..自己查手册吧,PHP发送头很容易.)

....
301 =>
"HTTP/1.1 301 Moved Permanently",
302 =>
"HTTP/1.1 302 Found",
303 =>
"HTTP/1.1 303 See Other",
307 =>
"HTTP/1.1 307 Temporary Redirect",
....

测试结果:

301,302和303的处理结果是一样的,直接跳转到test2.php,post没有内容

307的会重新post请求到test2.php,并且给出页面提示

302 Found请求的资源现在临时从不同的URI响应请求。由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下，这个响应才是可缓存的。注意：虽然RFC 1945和RFC 2068规范不允许客户端在重定向时改变请求的方法，但是很多现存的浏览器将302响应视作为303响应，并且使用GET方式访问在Location中规定的URI，而无视原先请求的方法。状态码303和307被添加了进来，用以明确服务器期待客户端进行何种反应。

303 See Other对应当前请求的响应可以在另一个URI上被找到，而且客户端应当采用GET的方式访问那个资源。这个方法的存在主要是为了允许由脚本激活的POST请求输出重定向到一个新的资源。这个新的URI不是原始资源的替代引用。同时，303响应禁止被缓存。当然，第二个请求（重定向）可能被缓存。注意：许多HTTP/1.1版以前的浏览器不能正确理解303状态。如果需要考虑与这些浏览器之间的互动，302状态码应该可以胜任，因为大多数的浏览器处理302响应时的方式恰恰就是上述规范要求客户端处理303响应时应当做的。

307 Temporary Redirect请求的资源现在临时从不同的URI响应请求。由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下，这个响应才是可缓存的。
302:目前很多浏览器的处理是重新发起GET

303: 如果发起的是POST，那么应该重新发送GET

307:如果发起的是POST，那么重新发送POST

303 和 307区分了302的没有明确定义的混乱状态.