当前位置:首页 > 运维 > 正文内容

HTTP状态码302、303和307的前世今生

phpmianshi5个月前 (01-28)运维184

背景

《HTTP权威指南》第3章在讲解30X状态码时,完全没有讲清楚为什么要有302、303、307,以及他们的关系,一句“问题出在HTTP1.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。

    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状态码也能正确运转,再考虑到微乎其微的兼容问题(现在的浏览器怎么可能不支持HTTP1.1呢!),也就没有使用303的必要了。



版权声明:本文由PHP面试资料网发布,如需转载请注明出处。
分享给朋友:

相关文章

守护进程详解及其代码实现

1、概念理解:守护进程(Daemon)是运行在后台的一种特殊进程,也称为精灵进程。是生存期较长的一种进程,常常在系统自举时启动,仅在系统关闭时终止。没有控制终端,仅仅在后台运行,Linux有很多守护进...

linux中netstat和ss命令详解

由于nio的普及,ck10k的问题已经成为过去式。现在随便一台服务器,都可以支持数十万级别的连接了。那么10万的连接需要多少资源呢?由于一个连接都是文件句柄,所以需要文件描述符数量支持才行,每一个so...

linux下utf-8 BOM的检查和删除

背景当源程序是gbk格式,你转换为 utf8 的时候,很多情况是头部会出现bom,当是php 程序时候,这样会出现很多意想不到的事情,那怎么办呢,你可以用linux 命令来查找,然后对文件的bom 进...

linux中配置内核参数sysctl详解

概念sysctl用于运行时配置内核参数,这些参数位于/proc/sys目录下。sysctl配置与显示在/proc/sys目录中的内核参数。用户只需要编辑/etc/sysctl.conf文件,即可手工或...






TCP(Transmission Control Protocol) 传输控制协议

三次握手

TCP是主机对主机层的传输控制协议,提供可靠的连接服务,采用三次握手确认建立一个连接:

位码即tcp标志位,有6种标示:

SYN(synchronous建立联机) 同步报文段

ACK(acknowledgement 确认)

PSH(push传送)

FIN(finish结束) 结束报文段

RST(reset重置) 复位报文段

URG(urgent紧急) 紧急指针

Sequence number(顺序号码)

Acknowledge number(确认号码)

客户端TCP状态迁移:

CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED

服务器TCP状态迁移:

CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED


各个状态的意义如下: 

LISTEN - 侦听来自远方TCP端口的连接请求; 

SYN-SENT -在发送连接请求后等待匹配的连接请求; 

SYN-RECEIVED - 在收到和发送一个连接请求后等待对连接请求的确认; 

ESTABLISHED- 代表一个打开的连接,数据可以传送给用户; 

FIN-WAIT-1 - 等待远程TCP的连接中断请求,或先前的连接中断请求的确认;

FIN-WAIT-2 - 从远程TCP等待连接中断请求; 

CLOSE-WAIT - 等待从本地用户发来的连接中断请求; 

CLOSING -等待远程TCP对连接中断的确认; 

LAST-ACK - 等待原来发向远程TCP的连接中断请求的确认; 

TIME-WAIT -等待足够的时间以确保远程TCP接收到连接中断请求的确认; 

CLOSED - 没有任何连接状态;


TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接,如图1所示。

(1)第一次握手:建立连接时,客户端A发送SYN包(SYN=j)到服务器B,并进入SYN_SEND状态,等待服务器B确认。

(2)第二次握手:服务器B收到SYN包,必须确认客户A的SYN(ACK=j+1),同时自己也发送一个SYN包(SYN=k),即SYN+ACK包,此时服务器B进入SYN_RECV状态。

(3)第三次握手:客户端A收到服务器B的SYN+ACK包,向服务器B发送确认包ACK(ACK=k+1),此包发送完毕,客户端A和服务器B进入ESTABLISHED状态,完成三次握手。

完成三次握手,客户端与服务器开始传送数据。

确认号:其数值等于发送方的发送序号 +1(即接收方期望接收的下一个序列号)。

图1 TCP三次握手建立连接  


TCP协议中的三次握手和四次挥手

理解:窗口和滑动窗口TCP的流量控制TCP使用窗口机制进行流量控制什么是窗口?连接建立时,各端分配一块缓冲区用来存储接收的数据,并将缓冲区的尺寸发送给另一端接收方发送的确认信息中包含了自己剩余的缓冲区...

nginx中request_time和upstream_response_time详解

背景最近监控报警有短暂的502,赶紧分析问题原因,查看nginx的access_log 发现短暂报警的request_time比较大,但是upstream_response_time有2个值,一个比较...

发表评论

访客

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。