HTTP 状态码 30X

作者：zccst

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,并且给出页面提示







今日读书，无法理解HTTP302、303、307状态码的来龙去脉，决定对其做深究并总结于本文。

    《HTTP权威指南》第3章在讲解30X状态码时，完全没有讲清楚为什么要有302、303、307，以及他们的关系，一句“问题出在HTTP/1/1”让我一头雾水，莫名其妙；而第五章在讲重定向响应时，没有说到现在很常见的302，反而是说我从没遇到过的303和307。很是迷惑，对于这3个状态码，WiKi和RFC文档都有详解，下面我以我的思维添油加醋的描述一遍。
一、状态码——302
    RFC1945(http://tools.ietf.org/html/rfc1945#page-34)，也就是HTTP1.0在介绍302时说，如果客户端发出POST请求后，收到服务端的302状态码，那么不能自动的向新的URI发送重复请求，必须跟用户确认是否该重发，因为第二次POST时，环境可能已经发生变化（嗯，POST方法不是幂等的），POST操作会不符合用户预期。但是，很多浏览器（user agent我描述为浏览器以方便介绍）在这种情况下都会把POST请求变为GET请求。
    RFC2616(http://tools.ietf.org/html/rfc2616#section-10.3.3)，也就是HTTP1.1在介绍302时说，如果客户端发出非GET、HEAD请求后，收到服务端的302状态码，那么就不能自动的向新URI发送重复请求，除非得到用户的确认。（又是-,-）但是，很多浏览器都把302当作303处理了（注意，303是HTTP1.1才加进来的，其实从HTTP1.0进化到HTTP1.1，浏览器什么都没动），它们获取到HTTP响应报文头部的Location字段信息，并发起一个GET请求。
二、状态码——303和307
    从上面的介绍可以知道，HTTP1.1和HTTP1.0的302状态码意义是一样的，浏览器对它的处理也是一样的。POST方法的重定向在未询问用户的情况下就变成GET，这种不符合文档规范的问题依然存在。实践在前而文档在后，HTTP1.1把这种POST变GET的行为纳入了RFC文档：HTTP1.1新加入303和307状态码。
    文档中规定303状态码的响应，也就是上边提到的现在浏览器对302状态码的处理：POST重定向为GET。
    307状态码则相当于HTTP1.0中302状态码，当客户端的POST请求收到服务端307的状态码的响应时，需要跟用户询问是否应该在新URI上发起POST方法，也就是说，307是不会把POST转为GET的。
    从网络上搜索到这个说法“303：对于POST请求，它表示请求已经被处理，客户端可以接着使用GET方法去请求Location里的URI。 307：对于POST请求，表示请求还没有被处理，客户端应该向Location里的URI重新发起POST请求。”，从上面的介绍可以明白，这个说法是臆想而已，文档并没有这么说，而业界是否统一如此处理，还不好说，我没有抓到过307和303的包。
    文档也说到，为兼容很多HTTP1.1之前的浏览器，服务端在需要发出303状态码时，会选择用302状态码替代；而对于307的处理，则需要在响应实体中包含信息，以便不能处理307状态码的用户有能力在新URI中发起重复请求，也就是说，把重定向的页面展示给用户，让用户去点重定向URI链接（URI现在基本就是URL）。
三、总结
    303和307是HTTP1.1新加的服务器响应文档的状态码，它们是对HTTP1.0中的302状态码的细化，主要用在对非GET、HEAD方法的响应上。文档规定：浏览器对303状态码的处理跟原来浏览器对HTTP1.0的302状态码的处理方法一样；浏览器对307状态码处理则跟原来HTTP1.0文档里对302的描述一样。
    303和307的存在，归根结底是由于POST方法的非幂等属性引起的。
    在HTTP1.1中，302理论上是要被放弃掉的，它被细化为303和307，但为了兼容，它目前还在业界中大量使用，而303和307状态码我还没遇到过（没有使用场景，也没抓到过这样的响应报文）。为什么业界少使用303和307呢？对于GET和HEAD方法来说，307是没必要存在的，用302或者303就可以满足需求了，307仅在POST方法的重定向上有用处。所以我猜测它们少见的原因有两方面：1、POST方法重定向的使用场景太少，使得307状态码没有用武之地；2、GET方法虽然常需要使用的重定向，但使用302状态码也能正确运转，再考虑到微乎其微的兼容问题（现在的浏览器怎么可能不支持HTTP1.1呢！），也就没有使用303的必要了。


如果您觉得本文的内容对您的学习有所帮助，您可以微信：