http协议进阶（三）http报文

1、报文流

http报文是在http应用程序之间发送的数据块（也可称为数据包）、这些数据块以一些文本的元信息（meta-information）开头，描述了报文的内容及含义，后面跟着

可选的数据部分，这些报文在客户端、服务器和代理之间流动；常说的术语“流入”、“流出”、“上游”、“下游”就是描述报文方向的

 

一、报文流入源服务器

http使用术语流入（inbound）和流出（outbound）来描述事务处理的方向；报文流入源服务器，工做完成后，流回用户的Agent代理中，以下图

 

二、报文向下游流动

无论是请求仍是响应报文，全部报文都会向下游流动，全部报文发送者都在接收者的上游，以下图

 

2、报文的组成

http报文是简单的格式化数据块，以下图

每条报文包含一个客户端请求或者服务端响应，由三部分组成：1）对报文进行描述的起始行；2）包含属性的首部（header）模块；3）可选的，包含数据的主体（body）部分

起始行和首部就是由行分隔的 ASCII文本。每行都以一个由2个字符组成的行终止序列做为结束，包括一个回车符（ASCII码13）和一个换行符（ASCII码10），这个行终止

序列能够写为CRLF。（稳健的应用程序也应该接受单个换行符做为行的终止）

实体或报文的主体是一个可选数据块，与起始行和首部不一样的是，主体中可包含文本或二进制数据，也能够为空

如上图，Content-type行说明了主体是一个纯文本文档，Content-length说明了主体有19字节

 

一、报文的语法

全部的http报文都分为请求报文和响应报文，请求报文会向服务器发送一个请求动做，响应报文会将请求结果返回给客户端，其结构基本相同；下图显示了获取一张GIF图所需的请求和响应报文

这是请求报文的格式                                             这是响应报文的格式

<method> <request-URL> <version>                            <method> <status> <version>

<headers>                                                   <heraers> 

<entity-body>                                               <entity-body>

下面是对各部分的简述：

方法（method）：客户端但愿服务器对资源执行的动做，是一个单独的词，好比GET、HEAD、POST等

以前的博客http://www.cnblogs.com/imyalost/p/5630940.html中有简单介绍几种方法，不事后面会详细解释这些方法

请求URL（request-URL）：命名了请求资源，或者URL路径组件的完整URL；若是直接与服务器进行对话，只要URL的路径是决定路径，一般不会出现问题（上一篇随笔有详细介绍URL......）

版本（version）：报文所使用的http协议版本——HTTP/<major>.<minor>;其中主要版本号（major）和次要版本号（minor）都是整数，本篇后面详解

状态码（status-code）：3位数字，描述请求过程当中发生的状况，每一个状态码第一位描述状态的通常类别（成功/错误），本篇后面解释http规范的状态码及其含义

以前的博客http://www.cnblogs.com/imyalost/p/5688169.html也有简单介绍

状态码还有一种可读版本，包含终止序列以前的版本；好比HTTP/1.1 200 NOT OK和HTTP/1.1 200 OK中缘由短语不一样，但一样被当作成功指示处理

首部（header）：能够有0个或多个首部，每一个首部包含一个名字，后面跟一个冒号，而后一个可选空格，接着一个值，最后是CRLF。首部由一个空行（CRLF）结束，表示首部列表的结束和实体主体的开始。

实体主体（entity-body）：包含一个由任意数据组成的数据块。

 

二、起始行

全部http报文都以一个起始行做为开始；请求报文说明了要作什么，响应报文说明发生了什么

2.1 请求行

请求报文请求服务器对资源进行一些操做。请求报文起始行，称为请求行，包含一个方法和一个请求。

该方法描述了服务器应该执行哪些操做，请求URL描述了要对哪一个资源执行这个方法，请求行中还包括http版本，告知服务器，客户端使用哪一个版本http协议，由空格符分隔

上图中，请求方法为GET，请求URL为test/hi-there.txt，http版本为1.1。

 

2.2 响应行

响应报文承载了状态信息和操做产生的全部结果数据，将其返回给客户端。响应报文起始行，称为响应行，包含了使用的http版本，数字状态码，以及描述操做状态或文本形式的缘由短语。

这些字段由空格符进行分隔，在上图中，http版本为1.0，状态码200（表示成功），缘由短语为OK，表示文档被成功返回。

 

2.3 方法

请求的起始行以方法做为开始，方法用来告知服务器作什么。如上图，方法就是GET,下表列出一些现版本http有的一些方法

具体的方法介绍下面会介绍

 

2.4 状态码

状态码用来告诉客户端，发生了什么事；状态码位于响应的起始行中。状态码在每条响应报文的起始行中返回的，以一个数字和一个可读的状态组成；数字码便于程序进行差错处理，缘由短语则便于理解

下面列出状态码的分类：

具体的方法介绍下面会介绍

 

2.5 缘由短语

缘由短语为状态码提供了文本形式的解释，和状态码成对出现，是状态码的可读版本，应用程序将其传给客户，说明在请求期间发生了什么；稍后会整理出一些状态码和其建议使用的一些缘由短语

 

2.6 版本号

版本号会以http/x、y的形式出如今请求和响应报文的起始行中，为应用程序提供了一种将本身遵循的协议版本告知对方的方式

通讯时最好使请求和响应的版本号保持一致，不然很容易形成误解，使程序没法识别

PS：版本号不会被当作分数处理，每一个数字都是独立的，好比，HTTP/2.22版本高于HTTP/2.3

 

三、首部

http首部字段向请求和响应报文中添加一些附加信息；本质来说，他们知识一些名/值对的列表。

 

3.1 首部分类

通用首部：便可出如今请求报文中，也可出如今响应报文中

请求首部：提供更多有关请求的信息

响应首部：提供更多有关响应的信息

实体首部：描述主体的长度和内容，或者资源自己

扩展首部：规范中没有定义的新首部

每一个http首部都有一种简单的语法：名字后面是冒号（：），而后跟上可选的空格，再跟上字段值，最后以一个CRLF结束

 

3.2 首部延续行

将长的首部行分为多行可提升可读性，每行前面至少有一个空格或制表符（tab），例如

HTTP/1.1 200 OK

Conteng-Type: image/gif

Content-Length: 8572

Server: Test Server

Version 1.0

上面的例子，响应报文中包含一个Server首部，其值被划分为多个延续行，该首部完整值为Server: Test Server Version 1.0

 

四、实体的主体部分

http报文的第三部分为可选的实体主体部分，实体是主体的http报文的负荷，就是http要传输的内容，资源

http报文可承载不少类型的数字数据：图片、视频、HTML文档、软件应用程序、电子邮件等

 

3、方法

一、GET

GET是最经常使用的方法，一般用于请求服务器发送某个资源（资源是已被服务器识别或标识的）给客户端； 以下图

服务器在获取GET请求参数时用Request.QueryString,意思为获取地址栏中的参数，就是“？”后面的参数，若是是多个，就用&连起来

 

二、HEAD

HEAD和GET方法相似，但在响应中只返回首部，不返回实体的主体部分。使用HEAD方法，能够

*在不获取资源的状况下了解资源的实际状况（资源类型）

*经过查看状态码，确认资源是否存在（有效性）

*经过查看首部，测试资源是否被修改（如修改，资源修改时间等）

 

三、PUT

与GET相反，PUT方法会向服务器写入文档（有些系统会容许用户建立web界面，并用PUT方法直接将其安装到web服务器上）

PUT方法实际上就是让服务器用请求中包含的主体部分来建立一个由请求的URL命名的新文档；或者URL已存在的话，就用这个主体来替代它。

由于PUT容许用户对内容进行修改，因此如今不多用这个方法，若是使用了这个方法，都要求用户使用受权的密码登录（后面会整理出来关于安全认证的相关内容）

 

四、POST

POST方法用来向服务器发送提交数据的请求，具体的内容这里就不赘述了，以前有写过关于这方面的随笔，里面介绍了post及它与get的区别等内容（http://www.cnblogs.com/imyalost/p/5630940.html）

 

五、TRACE

客户端发起一个请求时，请求可能要穿过防火墙、代理、网关或者其余应用程序，每一个中间节点可能都会修改原始的http请求，TRACE容许客户端在最终把请求发给服务器时，查看它最终的样子

TRACE请求会在目的服务器端发起一个“回环”诊断。最后一站服务器会弹回一个TEACE响应，并在响应报文主体中携带原始请求报文，这样客户端就能够查看在全部中间节点上，原始报文是否被修改或毁坏

 

六、OPTIONS

请求web服务器告知其支持的各类功能；能够询问服务器支持哪些方法，或者对某些特殊资源支持哪些方法（有些服务器可能只支持对一些特殊类型的对象使用特定操做）

为客户端提供了一种手段：不用实际访问资源就可断定访问各类资源的最优方式

 

七、DELETE

请求服务器删除请求URL所指定的资源；但客户端应用程序不必定会执行删除操做，由于http协议规范容许服务器在不通知客户端的状况下撤销请求。以下图

 

八、扩展方法

http被设计成可扩展的，这样新特性就不会使老的版本失效。扩展方法指的是没在HTTP/1.1中规范定义的，服务器为它管理的资源实现一些HTTP服务，为开发者提供了一种扩展这些HTTP服务能力的手段

下表列出了一些经常使用的扩展方法：

上面例子中的方法便于用过http将web内容发布到web服务器上

不是全部的扩展都是在正式规范中定义的，所以，扩展方法秉持“对发送内容要求严格，对所接受的内容宽容点”来处理通常的HTTP扩展方法很重要

 

4、状态码

响应报文的返回状态码分为五类，以前的随笔进行了介绍，这里就当作是补充吧

状态码是一种理解事务处理结果的便捷方式；下面列出一些常见的缘由短语例子，都是目前最经常使用的HTTP/1.1规范推荐使用的

一、100~199——信息性状态码

100 Continue的目的是对这样的状况进行优化：http客户端应用程序有一个主体的实体部分要发送给服务器，但发送以前但愿查看服务器是否会接受这个实体

 

1.1 客户端与100 Continue

若是客户端向服务器发送一个实体，并愿意在发送前等待100 Continue响应，那么客户端就要发送一个携带了值为100 Continue的EXpect请求首部；若是客户端没发送实体，

就不该发送100 Continue Expect首部。所以客户端只有在避免向服务器发送一个服务器没法处理或使用的较大的实体时，才应使用100 Continue

解决办法：发送了100 Continue的Expect首部值的客户端不该一直等待响应，超过必定时间（可设置），自动将实体发送出去；同时作好应对非预期100 Continue响应的准备

 

1.2 服务器与100 Continue

若是服务器收到带有值为100 Continue的Expect首部请求，它会用100 Continue或一条错误码来响应；服务器永远不该向没有发送100 Continue请求的客户端发送100 Continue状态码

若是服务器在发送100 Continue响应前收到部分或所有实体，说明客户端决定继续发送数据，此时，服务器不须要发送这个状态码，但读完请求，应继续返回一个最终状态码（跳过100 Continue状态）

若是服务器收到带有100 Continue的请求，且它决定在读完实体主体前结束请求，就不该仅仅发送一条响应并关闭链接，这样会影响客户端接收响应

 

1.3 代理与100 Continue

代理从客户端收到带有100 Continue指望的请求，有如下几种状况：

若是知道下游服务器是http/1.1兼容或不清楚下游服务器与哪个版本兼容，应将Expect首部放在请求中向下转发

若是知道下游服务器只能与http/1.1如下的版本兼容，就应该以417 Expectation Failed错误进行响应

若是代理决定表明与http/1.1或以前的版本兼容的客户端，在其请求中放入Expect首部和100 Continue值，那么它不该将100 Continue转发给客户端

 

二、200~299——成功状态码

下面列车一些服务器用来表示成功的状态码，分别对应不一样的请求

 

三、300~399——重定向状态码

告知客户端使用替代位置来访问它感兴趣的资源；或提供一个替代的响应而不是资源内容

或在资源已被移动状况下，发送一个重定向状态码和一个可选的Location首部告知客户端，资源已被移动，且在哪里能够找到寻找的资源，以下图：将请求重定向到新的位置

可经过某些重定向状态码对资源的应用程序本地副本与源服务器上的资源进行验证；好比http应用程序能够查看本地资源是不是最新的或者是否被修改过

总之，对那些包含了重定向状态码的非HEAD请求进行响应时，最好包含一个实体，其实体中包含描述信息和指向（多个）重定向URL的连接——如上图第一个响应报文

下表列出已定义的重定向状态码：

上面30二、303于307状态码之间存在一些交叉，区别在于HTTP/1.0和HTTP/1.1对其的处理方式：

当HTTP/1.0发起一个POST请求，并在响应中收到302重定向状态码时，它会接受Location首部重定向的URL，并向那个URL发起一个GET请求

若是HTTP/1.0服务器收到来自HTTP/1.0客户端的POST请求以后，发出302状态码，服务器但愿客户端能接受重定向URL并向重定向URL发一个GET请求

可是，HTTP/1.1规范使用303状态码来实现以上行为（服务器发送303状态码重定向客户端的POST请求，在其后面跟上一个GET请求）

为规避上述问题，HTTP/1.1规范：对于HTTP/1.1客户端，用307来取代302状态码进行重定向（保存302状态码，留待HTTP/1.0使用→→服务器遇到相似状况须要先检查客户端HTTP版本）

 

四、400~499——客户端错误状态码

有时候客户端会发送一些服务器没法处理的请求，好比格式错误的报文或者不存在的URL，服务器会返回给我状态码告诉咱们它的反应

不少客户端错误都由浏览器处理，只有少许错误，好比404，会被用户看到；下表列出各类客户端错误状态码

 

五、500~599服务器错误状态码

有时客户端发起一个请求，但服务器因为自己缺陷或子元素出错时，会出现此类问题，服务器返回5XX代码来描述遇到的问题

下表列出一些已定义的服务器错误状态码