301 Moved Permanently
被请求的资源已永久移动到新位置, 并且将来任何对此资源的引用都应该使用本响应返回的若干个 URI 之一. 如果可能, 拥有链接编辑功能的客户端应当自动把请求的地址修改为从服务器反馈回来的地址. 除非额外指定, 否则这个响应也是可缓存的.
新的永久性的 URI 应当在响应的 Location 域中返回. 除非这是一个 HEAD 请求, 否则响应的实体中应当包含指向新的 URI 的超链接及简短说明.
如果这不是一个 GET 或者 HEAD 请求, 因此浏览器禁止自动进行重定向, 除非得到用户的确认, 因为请求的条件可能因此发生变化.
注意: 对于某些使用 HTTP/1.0 协议的浏览器, 当它们发送的 POST 请求得到了一个 301 响应的话, 接下来的重定向请求将会变成 GET 方式.
302 Found
请求的资源现在临时从不同的 URI 响应请求. 由于这样的重定向是临时的, 客户端应当继续向原有地址发送以后的请求. 只有在 Cache-Control 或 Expires 中进行了指定的情况下, 这个响应才是可缓存的.
新的临时性的 URI 应当在响应的 Location 域中返回. 除非这是一个 HEAD 请求, 否则响应的实体中应当包含指向新的 URI 的超链接及简短说明.
如果这不是一个 GET 或者 HEAD 请求, 那么浏览器禁止自动进行重定向, 除非得到用户的确认, 因为请求的条件可能因此发生变化.
注意: 虽然 RFC 1945 和 RFC 2068 规范不允许客户端在重定向时改变请求的方法, 但是很多现存的浏览器将 302 响应视作为 303 响应, 并且使用 GET 方式访问在 Location 中规定的 URI, 而无视原先请求的方法. 状态码 303 和 307 被添加了进来, 用以明确服务器期待客户端进行何种反应.
详细来说, 301 和 302 状态码都表示重定向, 就是说浏览器在拿到服务器返回的这个状态码后会自动跳转到一个新的 URL 地址, 这个地址可以从响应的 Location 首部中获取 (用户看到的效果就是他输入的地址 A 瞬间变成了另一个地址 B)-- 这是它们的共同点. 他们的不同在于. 301 表示旧地址 A 的资源已经被永久地移除了 (这个资源不可访问了), 搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址; 302 表示旧地址 A 的资源还在 (仍然可以访问), 这个重定向只是临时地从旧地址 A 跳转到地址 B, 搜索引擎会抓取新的内容而保存旧的网址.
来源: http://www.bubuko.com/infodetail-2548983.html