100字范文 > Http权威指南笔记(三)——HTTP报文

Http权威指南笔记(三)——HTTP报文

时间：2023-08-05 15:21:41

前面介绍了URL是用于定位服务器上的资源。但是定位到资源后，通过什么样的方式、规定来让客户端和服务端进行交流呢？这就是本篇要介绍的HTTP报文。

1 报文流

HTTP 报文是在 HTTP 应用程序之间发送的数据块。这些数据块以一些文本形式的元信息（meta-information）开头。这些报文在客户端、服务器和代理之间流动。术语“流入”、“流出”、“上游”及“下游”都是用来描述报文方向的。一个示例如下图所示：

1.1 报文向下流动

HTTP 报文会像河水一样流动。不管是请求报文还是响应报文，所有报文都会向下游（downstream）流动。所有报文的发送者都在接收者的上游（upstream）。如下图所示中，对请求报文来说，代理 1 位于代理 3 的上游，但对响应报文来说，它就位于代理 3 的下游 1。

2 报文组成部分

一条HTTP报文一般由如下部分组成：对报文进行描述的起始行（start line）、包含属性的首部（header）块，以及可选的、包含数据的主体（body）部分。示例如图：

如上图所示，start line和header一般都有ASCII码组成，每行都由CRLF标识作为结束终止，但是有些程序也会用单个换行符作为结束标志。body部分另外两个组成部分不太一样，除了可以包含文本外，还可以包含一些二进制数据。

2.1 报文的语法

HTTP报文分为两类：请求报文和响应报文。两类报文的格式如下：

请求报文

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

请求报文：

<version> <status> <reason-phrase><headers><entity-body>

每个部分简要介绍如下：

方法（method）：客户端希望对服务器进行的操作动作，如：GET, POST请求URL（request-URL）：“、命名了所请求资源，或者 URL 路径组件的完整 URL。版本（version）：报文所使用的HTTP版本，格式：HTTP/<major>.<minor>状态码（status-code）：描述请求过程中所发生的情况。原因短语（reason-phase）：用用户对前面状态码的简短描述，主要用于给用户看的。首部（header）：可以有零个或多个首部，每个首部都包含一个名字，后面跟着一个冒号（:），然后是一个可选的空格，接着是一个值，最后是一个 CRLF。实体部分（entity-body）：实体的主体部分包含一个由任意数据组成的数据块。

2.2 起始行

所有的 HTTP 报文都以一个起始行作为开始。分为请求行和向应行。

请求行：包含了一个方法和一个请求URL，还有HTTP版本。这些字段都有空格分开响应行：包含了响应报文使用的HTTP版本，数字状态，以及描述状态码的原因短语。

2.2.1 方法

请求的起始行以方法作为开始，方法用来告知服务器需要做什么，HTTP规范中定义了常用的方法如下：

除了这些方法外，我们还可以自定义一些扩展方法。

2.2.2 状态码

方法是用来告诉服务器做什么事情的，状态码则用来告诉客户端，发生了什么事情。状态码位于响应行中，如：HTTP/1.0 200 OK中，200即为状态码。HTTP中状态码分类如下：

常见状态码如下：

2.2.3 原因短语

原因短语是响应起始行中的最后一个组件。它为状态码提供了文本形式的解释。比如，在行 HTTP/1.0 200 OK 中，OK 就是原因短语。

2.2.4 版本号

版本号会以 HTTP/x.y 的形式出现在请求和响应报文的起始行中。版本号说明了应用程序支持的最高 HTTP 版本。

有个注意的地方，版本号不会被当作小数来处理。版本中的每个数字（比如 HTTP/1.0 中的 1 和 0）都会被当作一个单独的数字来处理。比如，HTTP/2.22 就比 HTTP/2.3 的版本要高，因为 22 比 3 大。

2.3 首部

前面介绍了请求和响应的第一行数据——起始行，接下来介绍首部。

HTTP 首部字段向请求和响应报文中添加了一些附加信息。本质上来说，它们只是一些键值对的列表。首部一般分为以下几类：通用首部、请求首部、响应首部、实体首部、扩展首部。

每个 HTTP 首部都有一种简单的语法：名字后面跟着冒号（：），然后跟上可选的空格，再跟上字段值，最后是一个 CRLF。

常见首部示例如下：

首部一个键可以对应多个值，如果出现此种情况，为了提高可读性，多出来的行每行前面至少要有一个空格或制表符，如：

HTTP/1.0 200 OKContent-Type: image/gifContent-Length: 8572Server: Test ServerVersion 1.0

2.4 实体部分(body)

HTTP 报文的第三部分是可选的实体主体部分。实体的主体是 HTTP 报文的负荷。就是 HTTP 要传输的内容。

HTTP 报文可以承载很多类型的数字数据：图片、视频、HTML 文档、软件应用程序、信用卡事务、电子邮件等。

3 方法

上面我们也提到过方法，现在对方法进行一个详细的说明。

HTTP1.1要求，每台服务器必须要实现GET和HEAD方法，其他方法可以选择实现，也可以选择不实现。同时HEAD和GET也被称为安全方法，因为这两个方法不会对请求的资源产生任何动作。

3.1 GET

GET 是最常用的方法。通常用于请求服务器发送某个资源。HTTP/1.1 要求服务器实现此方法。一个示例如下：

3.2 HEAD

HEAD 方法与 GET 方法的行为很类似，但服务器在响应中只返回首部。使用HEAD方法，可以达到如下效果：

在不获取资源的情况下了解资源的情况(如：判断内容类型)；通过查看响应码，了解该资源是否存在；通过查看首部，检验资源是否被修改了

3.3 PUT

与 GET 从服务器读取文档相反，PUT 方法会向服务器写入文档。PUT方法会让服务器创建一个所请求URL命名的新文档，如果该文档已经存在，则会更新。

一个PUT请求示例如下：

3.4 POST

POST 方法起初是用来向服务器输入数据的。实际上，通常会用它来支持 HTML 的表单。这里注意其与PUT方法的区别是POST仅仅是用来给服务器发送数据，至于数据怎么处理完全由服务器自己决定，而PUT方法是让服务器存储数据的。

3.5 TRACE

客户端发起一个请求时，这个请求可能要穿过防火墙、代理、网关或其他一些应用程序。每个中间节点都可能会修改原始的 HTTP 请求。TRACE 方法允许客户端在最终将请求发送给服务器时，看看它变成了什么样子。其一般用于诊断请求过程中是否被修改或者毁坏。TRACE 请求中不能带有实体的主体部分。

一个TRACE请求如下：

3.6 OPTIONS

OPTIONS 方法请求 Web 服务器告知其支持的各种功能。可以询问服务器通常支持哪些方法，或者对某些特殊资源支持哪些方法。

3.7 DELETE

顾名思义，DELETE 方法所做的事情就是请服务器删除请求 URL 所指定的资源。但是，客户端应用程序无法保证删除操作一定会被执行。因为 HTTP 规范允许服务器在不通知客户端的情况下撤销请求。

3.8 扩展方法

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

4 状态码

状态码总体被分为5大类，之前已经介绍过了。这里我们针对没类做一些介绍。

4.1 100~199信息状态码

4.2 200~299成功状态码

客户端发起请求时，这些请求通常都是成功的。服务器有一组用来表示成功的状态码。

4.3 300~399重定向状态码

重定向状态码要么告知客户端使用替代位置来访问他们所感兴趣的资源，要么就提供一个替代的响应而不是资源的内容。如果资源已被移动，可发送一个重定向状态码和一个可选的 Location 首部来告知客户端资源已被移走，以及现在可以在哪里找到它。请求示例如下：

常见的重定向状态码如下：

其中302，303，307的区别如下：

302 主要是HTTP1.0的状态码，本身规定是除非是HEAD或者GET请求，否则必须经过用户同意才能重定向，但是一般浏览器处理是直接重定向到新的URL了。303 HTTP1.1新添加的。由于之前浏览器对302的处理大部分都是直接重定向了，所以新的HTTP协议细分出了303和307，303是允许浏览器自动重定向的。307 HTTP1.1新添加。除非是GET或者HEAD请求，否则需要用户同意才能重定向。

这几个状态码总的说来关系就是，HTTP1.0的时候只有302，要求非GET或HEAD请求必须经用户同意才能重定向，但是大部分浏览器并没有这样做，所以在HTTP1.1的时候，将302细分出了303和307。303是可以自动重定向，307要求非GET或者HEAD必须经用户同意，保留302是为了和1.0版本兼容。