HTTP报文概览

本文主要对报文的流动及其内容的理解做了介绍。包括以下内容：

• 报文的流动

• 报文的组成部分（起始行、首部和实体的主体部分）

• 报文的区别（响应报文和请求报文之间）

• 方法介绍

• 状态码介绍

• HTTP首部作用

这里要强调的是，这个最多是我抄书的理解，并不全面。请大家看的时候还需要用慧眼进行鉴别。

一、报文的流动

HTTP报文是指在HTTP应用程序之间收发的数据块。其以文本形式的元信息开头，描述报文的内容和含义，而后接续可选部分。这里有三个术语：

• 流入（inbound）

• 流出（outbound）

• 事务处理（transaction）

流入是指从客户端到服务器的事务处理方向；而流出则是从服务器到客户端的事务处理方向。但不管是哪种流动，所有报文都向下（downstream）流动，而报文的发送者都在接受者的上游（upstream）。注意，这里的上游和下游都只和发送者、接受者有关，而服务器和客户端都是下游节点，所以我们无法区别报文的发送方向。

二、报文的组成部分

HTTP报文分请求报文和响应报文两种，它们都由三个部分组成：

• 起始行：对报文进行描述。

• 首部：包含属性

• 主体：可选的，包含数据。

起始行和首部是由行分隔的ASCII文本，都包括了一个回车符和一个换行符，可写作CRLF。但是，由于部分HTTP应用程序不总是发送CRLF，所以一个HTTP应用程序应该接受单个换行符作为终止。主体可以包含文本或者二进制数据，也可以为空。

1.语法

HTTP报文分为两类，而语法不同。请求报文的格式为：

    <method> <request-URL> <version>
    <headers>
    
    <entity-body>

而响应报文在格式上，只有起始行有别：

    <version> <status> <reason-phrase>

接下来将对其中的大部分内容进行详细介绍，而实体则在日后详谈。这里简述下实体<entity-body>：包含一个由任意数据组成的数据块，是可选的。

2.起始行

起始行分为请求行和响应行。

2.1.请求行

请求报文的起始行，包含一个方法和一个请求URL。方法描述需要执行的操作，而请求URL则描述操作对象。请求行还包含客户端的HTTP协议版本。这些字段使用空格符” “分隔。注意，在HTTP/0.9不要求请求中包含HTTP版本号。

2.2.响应行

响应报文的起始行，包含响应报文使用的HTTP协议版本、数字状态码和原因短语。所有字段使用空格符” “分隔。

2.3.方法

告知服务器要进行的操作。HTTP规范中描述了一组方法，而在HTTP规范之外的方法，则是扩展方法，是HTTP规范的拓展。常用HTTP方法有：

2.4.状态码

服务器对客户端操作结果的回应。状态码有五种分类，而当前HTTP版本只规定了其中一部分。如果接收到拓展的状态码，则会按照其所属范围进行分类，而后按照该分类中的普通成员处理。状态码分类如下：

后面会解释当前使用的所有状态码，这里按下不表。

2.5.原因短语

与状态码同时出现，是其文本形式，但是HTTP规范对此并没有任何规定,但是有推荐的文本内容。

2.6.版本号

以HTTPx.y出现,使得HTTP客户端和服务器可以了解双方的能力和报文。注意，其版本号不会被当作小数处理，每一个数字都会单独比较。

3.首部

其作用是向报文添加附加信息，本质上是名/值对的列表，用冒号”:”分开名与值，可以分为五种：通用首部、请求首部、响应首部、实体首部和扩展首部。首部的语法如下：
<headers>: (可选的空格)<value>\r\n
首部可以有多行，为了增强可读性，从第二行开始要在前面加一个空格或者制表符。

4.实体的主体部分

是HTTP报文的符合，即其要传输的内容。HTTP报文可以承载多种类型的数字数据，包括HTML文档、图片、视频等。

5.HTTP0.9的报文

这是HTTP协议早期版本，由请求和响应构成，但是请求中只包含方法和请求URL，而响应中只包含实体。由于其却放灵活性，不能使用大部分提到的方法，但是在部分应用上仍旧使用，开发者应该清楚其局限。

三、方法

这部分是对前面的基本方法的深入探讨。有以下几点要注意：

• 并不是每个服务器实现了所有方法

• 服务器中部分方法的使用可能是受限的，而限制则在服务器的配置中进行设置。

1.安全方法

这是由HTTP协议定义的，其中包括GET和HEAD方法。安全方法意味着不产生动作，但这由Web开发者决定。相对应的，使用不安全的方法时，会允许HTTP应用开发者通知用户，这才是目的。

2.GET方法

常用方法，用于请求服务器发送某个资源，在HTTP/1.1中，要求服务器实现该方法。

3.HEAD方法

类似GET方法，但是响应只返回首部。目的是允许客户端对资源的首部进行检查。该方法有以下作用：

• 不获取资源的前提下了解资源情况

• 查看对象是否存在

• 测试资源是否被修改

规范要求其返回的首部于GET方法获得的相同。

4.PUT方法

向服务器写入文档，其方法的语义即让服务器用请求的主体部分（body）创建或者覆盖所请求的URL命名的新文档。由于其允许用户修改文件，通常要求进行密码认证。该方法需要存储资源。

5.POST方法

起初用来输入数据，现多用来支持HTTP表单。表单体拿到的数据发送给服务器，再由服务器决定去向。该方法不需要存储资源。

6.TRACE方法

在客户端发起请求以后，当它穿过其他应用程序的中间节点时可能被修改。而TRACE方法允许客户端最后将请求发送给服务器。
该请求会进行“环回”诊断，即在服务器弹回一条携带收到的报文的TRACE响应，使得客户端能查看原始报文的修改情况。TRACE方法用于诊断，验证请求是否穿过了请求/响应链，但由于其假设中间应用程序对各种不同类型的请求的处理相同，所以其不能区别HTTP程序对不同方法的处理机制的差异。
TRACE请求中不能带有实体的主体部分。响应主体则包含收到的请求主体的精确副本。

7.OPTIONS方法

请求Web服务器告知其支持的所有方法，这些方法是通用于服务器上所有资源的。这使得客户端可以判定请求资源的最优方法。（就是优化）

8.DELETE方法

请求服务器删除请求URL指定的资源，但是客户端程序不保证删除操作被执行。

9.拓展方法

由于HTTP被设计为字段可拓展的，新旧特性可以兼容。而拓展方法指的是：没有在HTTP/1.1规范中定义的方法。常见拓展方法实例如下：

上面的拓展方法是在WebDAV HTTP拓展中定义的拓展方法。要注意的是，并非所有拓展方法都可以被理解或者应用，所以，最好对拓展方法宽容以待，只要不破坏端到端行为，可以传递给下游服务器；如果可能破坏，则传递501 Not Implemented进行响应。惯例是：“对发送的内容要求严格，对接受的内容要求宽松”。

四、状态码

目的是便利客户端理解事务处理的结果，分为五大类，而五大类中的每个状态码都有一个HTTP/1.1推荐使用的原因短语。

1.信息性状态码100~199

在HTTP/1.1中引入，存在争论，受到限制。其主要内容如下：

在这里，要对100状态码进行一个解释。其针对的情境是：客户端需要发送一个实体给服务器，但要在发送之前检查一下服务器是否会接受该实体。而它在客户端、服务器和代理之间是这样通信的：

客户端与100状态码

客户端可以发送一个携带了值为100Continue的Expect请求首部，从而可以在发送实体之前等待100Continue的响应。这用于避免向服务器发送一个无法处理的大实体。注意，如果等待超时，则客户端应该直接发送实体；要应对非预期的响应。

服务器与100状态码

服务器在收到带有值为100Continue的Expect首部的请求时，应该用100Continue或者其他错误状态码进行响应。但是，如果客户端没有要求，则服务器不应该发送该响应。
如果服务器在发送100Continue之前就收到部分实体，即客户端已经超时了，服务器就不需要发送100状态码，但是读完请求以后，应该发送一个最终状态码（可跳过100状态码）。

代理与100状态码

代理收到一个100Continue的Expect请求，则能做的分以下几种情况：

• 知道下一跳服务器是HTTP/1.1兼容（或者不知道），则将Except首部向下转发

• 知道下一跳服务器只与HTTP/1.1之前兼容，则应该响应417Exception Failed错误（或者是先向客户端返回100Continue，而后在向服务器转发请求的时候，删除Except首部）。

• 代理代表与HTTP/1.0或之前的版本兼容的客户端，则可以向请求中放入Except首部与100Continue值，但是不能向客户端转发该状态码。
  所以，代理维护下一跳服务器及其版本信息有优点：更好地处理100Continue期望的请求。

2.成功状态码200~299

成功的请求有不同类型，所以下面有不同的表示成功的状态码。

3.重定向状态码300~399

告知用户使用替代位置来访问资源，或者提供一个替代的响应而不是资源内容。如果资源已移动，则可以发送重定向状态码以及一个可选的Location首部来告知客户端资源已被移动，以及当前位置。这样浏览器可以透明转入新的位置。
也可以通过重定向状态码验证本地资源与服务器资源，用于查看服务器资源的修改，以及保持本地副本的及时性。
对包含了重定向状态码的非HEAD请求进行响应，则包含一个实体，并在实体中描述信息和指向（多个）重定向URL的连接。

状态码302、303、307之间存在交叉和细微的差别，而其源于HTTP/1.0和HTTP/1.1应用程序之间的差别。
对于HTTP/1.0客户端，发起POST请求并收到302响应时，会接受Location首部的重定向URL，并发送GET请求。
对HTTP/1.0服务器，要求客户端像上面一样做。
但是HTTP/1.1使用303状态码实现相同行为，所以，对于HTTP/1.1客户端，使用307状态码来代理302状态码，以避免302状态码被覆盖。

4.客户端错误状态码400~499

服务器收到无法处理的内容时的响应。

有一个403Forbidden，好像是服务器拒绝处理请求，并且不说明原因。

5.服务器错误状态码500~599

客户端的请求有效，但是服务器出错时，可以使用，这是通常是代理与服务器交流的结果。

五、首部

首部与方法配合使用，决定服务器和客户端的动作。其有五种首部，在下面进行详细论述。

1.通用首部

提供与报文相关的最基本的信息，可以由两种报文使用。信息性首部有：

而通用缓存首部则是在HTTP/1.0中引入的，允许HTTP应用程序缓存本地副本的首部，而不用直接从服务器中获取。基本的缓存首部如下：

2.请求首部

在请求报文中特有的内容。对服务器提供更详细的有关客户端的信息。其信息性首部有：

2.1.Accept首部

为客户端提供将器喜好和能力告知服务器的方式，从而使得连接的两端都得益。主要的Accept首部如下：

2.2.条件请求首部

为请求加上限制，要求服务器在响应之前，确保条件为真。

2.3.安全请求首部

对请求进行质询后者响应认证。要求客户端在获取特定资源之前，对自身进行认证，从而提高事务安全性。

2.4.代理请求首部

由于代理的普遍应用而来。

3.响应首部

由响应报文使用，为客户端提供额外的信息，包括信息性首部、协商首部和安全响应首部。信息性首部如下：

而协商首部则是用来传递与可协商资源有关的信息。

安全响应首部则是HTTP的质询/响应认证机制的响应侧。安全响应首部如下：

4.实体首部

可以出现在两种报文中，提供有关实体及其内容的大量信息，其信息性首部有：

内容首部包含的是与实体内容有关的特定信息。

缓存首部则说明了被缓存的主体的信息。

这里就是本章的全部内容，虽然有一些图有所缺漏，但是至少看懂HTTP报文大概是怎么回事应该没问题了。