状态码–302
HTTP1.0在介绍302时说，如果客户端发出POST请求后，收到服务端的302状态码，那么不能自动的向新的URL发送重复请求，必须跟用户确认是否该重发，因为第二次POST时，环境可能已经发生变化（嗯，POST方法不是幂等的），也就是HTTP1.1在介绍302时说，如果客户端发出非GET、HEAD请求后，收到服务端的302状态码，那么就不能自动的向新的URL发送重复请求，除非得到用户的确认。但是，很多浏览器都把302当做303处理了，他们获取到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。
HTTP1.1文档中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状态码也可以正确运转，再考虑到微乎其微的兼容问题，也就没有使用的必要了。
