HTTP 报文 之 HTTP 状态码

如前面所示,HTTP 状态码被分成了五大类。本节对这五类 HTTP 状态码中的每一类都进行了总结。

100~199——信息性状态码

HTTP/1.1 向协议中引入了信息性状态码。这些状态码相对较新,关于其复杂性和感知价值存在一些争议,而受到限制。

状态码   原因短语   含义  
100   Continue    说明收到了请求的初始部分,请客户端继续。发送了这个状态码之后,服务器在收到请求之后必须进行响应。更多信息请参见附录 C 中的 Expect 首部介绍。  
101   Switching Protocols   说明服务器正在根据客户端的指定,将协议切换成 Update 首部所列的协议。  

客户端与 100 Continue 

如果客户端在向服务器发送一个实体,并且愿意在发送实体之前等待 100 Continue 响应,那么,客户端就要发送一个携带了值为 100 Continue 的 Expect 请求首部(参见附录C)。如果客户端没有发送实体,就不应该发送 100 Continue Expect 首部,因为这样会使服务器误以为客户端要发送一个实体。

服务器与 100 Continue 

如果服务器收到了一条带有值为 100 Continue 的 Expect 首部的气你去,它会用 100 Continue 响应或一条错误码来进行响应。服务器永远也不应该向没有发送 100 Continue 期望的客户端发送 100 Continue 状态码。

如果出于某种原因,服务器在有机会发送 100 Continue 响应之前就收到了部分(或全部)的实体,就说明客户端已经决定继续发送数据了,这样,服务器就不需要发送这个状态码了。但服务器读完请求之后,还是应该为请求发送一个最终的状态码(它可以跳过 100 Continue 状态)。

代理与 100 Continue

如果代理从客户端收到了一条带有 100 Continue 期望的请求,它需要做几件事情。如果代理知道下一跳服务器是 HTTP/1.1 兼容的,或者并不知道下一跳服务器与哪个版本兼容,它都应该将 Expect 首部放在请求中向下转发。如果它知道下一跳服务器只能与 HTTP/1.1 之前的版本兼容,就应该以 417 Expectation Failed 错误进行响应。

如果代理决定代表与 HTTP/1.0 或之前版本兼容的客户端,在其请求中放入 Expect 首部和 100 Continue 值,那么,(如果它从服务器收到了 100 Continue 响应)它就不应该将 100 Continue 响应转发给客户端,因为客户端可能不知道该拿他怎么办。

200 ~ 299 —— 成功状态码

客户端发起请求时,这些请求通常都是成功的。服务器有一组用来表示成功的状态码,分别对应于不同类型的请求。

状态码   原因短语   含义  
200   OK   请求没问题,实体的主体部分包含了所请求的资源。  
201   Created   用于创建服务器对象的请求(比如,PUT)。响应的实体主体部分中应该包含各种引用了已创建的资源的URL,Location 首部包含的则是最具体的引用。服务器必须在发送这个状态码之前创建好对象。  
202   Accepted   请求已被接受,但服务器还未对其执行任何动作。不能保证服务器会完成这个请求;这只是意味着接受请求时,它看起来是有效的。服务器应该在实体的主体部分包含对请求状态的描述,或许还应该有对请求完成时间的估计(或者包含一个指针,指向可以获取此信息的位置)。  
203   Non-Authoritative Information  

实体首部包含的信息不是来自于源端服务器,而是来自资源的一份副本。如果中间节点上有一份资源副本,但无法或者没有对它所发送的资源有关的元信息(首部)进行验证,就会出现这种情况。

这种响应码并不是非用不可的;如果实体首部来自源端服务器,响应为200状态的应用程序就可以将其作为一种可选项使用。

 
204   No Content   响应报文中包含若干首部和一个状态行,但没有实体的主体部分。主要用于在浏览器不转为显示新文档的情况下,对其进行更新(比如刷新一个表单页面)。  
205   Reset Content   另一个主要用于浏览器的代码。负责告知浏览器清除当前页面中的所有 HTML 表单元素  
206   Partial Content   

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/5af036edbd300e97f529329396e8c719.html