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

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

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

关于html状态码错误的是,关于 HTTP 307 状态码_第1张图片

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 方法的非幂等属性引起的。

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

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

你可能感兴趣的:(关于html状态码错误的是)