关于html状态码错误的是,关于 HTTP 307 状态码

关于各种 HTTP 状态码可以说是虽不曾深入，但也算有所了解，而在写关于什么是 HSTS 安全协议的时候，猛然间发现 不是很常见的 307 状态码，因为我们平常见的都是 301，302，就连 303 就没怎么讲过，而子凡觉得有必要单独的给 307 状态码开个专题讲座。

子凡也作为一个边学变卖的状态来给大家做这个讲座专题吧！首先我们肯定还是先简单的回顾一下常见的：

302 状态码

在 POST 请求方式上，客户端收到服务端的 302 状态码，那么不能自动的向新的 URI 发送重复请求，必须跟用户确认是否该重发，因为第二次 POST 时，环境可能已经发生变化(POST 方法不是幂等)，POST 操作会不符合用户预期。但是很多浏览器(user agent)在这种情况下都会把 POST 请求变为 GET 请求。

如果客户端发出非 GET、HEAD 请求后，收到服务端的 302 状态码，那么就不能自动的向新 URI 发送重复请求，除非得到用户的确认。但是，很多浏览器都把 302 当作 303 处理了(注意，303 是 HTTP1.1 才加进来的，其实从 HTTP1.0 进化到 HTTP1.1，浏览器什么都没动)，它们获取到 HTTP 响应报文头部的 Location 字段信息，并发起一个 GET 请求。

303/307 状态码(这才是我文章要讲的重点)

在 GET、HEAD 这些幂等的请求方式上，302、303、307 没啥区别，而对于 POST 就不同了，大部分浏览器 都会 302 会将 POST 请求转为 GET，而 303 是规范强制规定将 POST 转为 GET 请求，请求地址为 header 头中的 Location，307 则不一样，规范要求浏览器继续向 Location 的地址 POST 内容。

而在 HSTS 中，307 可以被缓存，缓存时间根据 max-age 而定，一般建议缓存 1 年甚至更长。

写在最后

303 和 307 是 HTTP1.1 新加的服务器响应文档的状态码，它们是对 HTTP1.0 中的 302 状态码的细化，主要用在对非 GET、HEAD 方法的响应上。文档规定：浏览器对 303 状态码的处理跟原来浏览器对 HTTP1.0 的 302 状态码的处理方法一样；浏览器对 307 状态码处理则跟原来 HTTP1.0 文档里对 302 的描述一样。

303 和 307 的存在，归根结底是由于 POST 方法的非幂等属性引起的。

子凡也是作为一个边学变卖的状态来给大家做的这个讲座专题，一方面是自己做个记录，另一方面就是也给大家同样的学习和了解一下，虽然很多时候都不会见到，但是学习永无止境嘛！哈哈哈

除非注明，否则均为泪雪博客原创文章，禁止任何形式转载