HTTP 报文

参考资料

• 《HTTP 权威指南》

引言

本篇主要详细介绍 HTTP 报文相关的知识。

一、报文流

• HTTP 报文是在 HTTP 应用程序之间发送的数据块。这些数据块以一些文本形式的 ** 元信息 ** 开头这些信息描述了报文的内容及含义，后面跟着可选的数据部分，这些报文在客户端、服务端和代理之间流动。
• 报文流入源端服务器：HTTP 使用术语 流入 和 流出 来描述 事务处理 的方向。报文流入源端服务器，工作完成之后，会流回用户的 Agent 代理中。

报文流入源端服务器并回流到客户端

• 报文向下游流动：所有报文的发送者都在接收者的上游。

所有报文都向下游流动

二、报文的组成部分

• HTTP 报文是简单的格式化数据块。每条报文都包含一条来自 客户端的请求 或 服务器的响应。它们由三部分组成：对报文进行描述的起始行（start line）、包含属性的首部（header）块，以及可选的、包含数据的主体（body）部分。
• 起始行和首部就是由行分隔的 ASCII 文本，每行都以一个由两个字符（回车符 ASCII 13 和换行符 ASCII 10）组成的行终止序列作为结束。但考虑兼容低版本 HTTP 应用程序，稳健的应用程序也应该接受单个换行符作为行的终止。
• 实体的主体或报文的主体是一个可选的数据块。与起始行和首部不同的是，主体中可以包含文本或二进制数据，也可以为空。

HTTP 报文的三个部分

2.1 报文的语法

• 所有的 HTTP 报文都可以分为两类：请求报文 和 响应报文 。请求报文会向 Web 服务器请求一个动作，响应报文会将请求的结果返回给客户端。请求和响应报文的基本报文结构相同。

包含请求和响应报文的 HTTP 事务

• 请求报文的格式：

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

• 响应报文的格式：

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

<entity-body>

• 对各部分的简要描述：

• method： 客户端希望服务器对资源执行的动作。是一个独立的词，比如 GET、HEAD 或 POST。

• request-URL： 命名了所请求资源，或者 URL 路径组件的完整 URL。
• version： 报文所使用的 HTTP 版本 HTTP/<major>.<minor>
• status-code：这三位数字描述了请求过程中所发生的情况。
• reason-phrase：数字状态码的可读版本，包含行终止序列之前的所有文本。
• header：可以有零个或多个首部，每个首部都包含一个名字，后面跟着一个冒号，然后是一个可选的空格，接着是一个值，最后是一个 CRLF。
• entity-body：实体的主体部分包含一个由任意数据组成的数据块。

请求和响应报文示例

2.2 起始行

所有的 HTTP 报文都以一个起始行作为开始。请求报文的起始行说明了 要做些什么，响应报文的起始行说明 发生了什么。

• 请求行：请求报文的起始行，或称为请求行，包含了一个方法和一个请求 URL，这个方法描述了服务器应该执行的操作，请求 URL 描述了要对哪个资源执行这个方法。请求行中还包含 HTTP 的版本，用来告知服务器，客户端使用的是哪种 HTTP。

• 响应行：响应报文承载了状态信息和操作产生的所有结果数据，将其返回给客户端。响应报文的起始行，或称为响应行，包含了响应报文使用的 HTTP 版本、数字状态码，以及描述操作状态的文本形式的原因短语。

• 方法：请求的起始行以方法作为开始，方法用来告知服务器要做些什么。常用的 HTTP 方法如下：

常用的 HTTP 方法

• 状态码：状态码是用来告诉客户端，发生了什么事情。常见的状态码分类如下：

状态码分类

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

• 版本号：版本号会以 HTTP/x.y 的形式出现在请求和响应报文的起始行中，为 HTTP 应用程序提供了一种将自己所遵循的协议版本告知对发的方式。

2.3 首部

HTTP 首部字段向请求和响应报文中添加了一些附加信息。本质上说，它们只是一些 名/值 对的列表。比如，下面的首部行会向 Content-Length 首部字段赋值 19：Content-length: 19

• 首部分类：
• 通用首部：既可以出现在请求报文中，也可以出现在响应报文中。
• 请求首部：提供更多有关请求的信息。
• 响应首部：提供更多有关响应的信息。
• 实体首部：描述主体的长度和内容，或者资源自身。
• 扩展首部：规范中没有定义的新首部。

常见的首部实例

• 首部延续行：将长的首部分为多行，可以提高可读性，多出来的每行前面至少要有一个空格或制表符。

HTTP/1.0 200 OK
Content-Type: image/gif
Content-Length: 8572

Server: Test Server
    Version 1.0

2.4 实体的主体部分

• HTTP 报文的第三部分是可选的实体主体部分。实体的主体是 HTTP 报文的负载。HTTP 报文可以承载很多类型的数字数据：图片、视频、HTML 文档、软件应用程序、信用卡事务、电子邮件等。

三、方法

3.1 GET

• GET 是最常用的方法，通常用于请求服务器发送某个资源。

GET 示例

3.2 HEAD

• HEAD 方法与 GET 方法的行为很类似，但服务器在响应中只返回首部，不会返回实体的主体部分。主要的使用场景有以下几种：
• 在不获取资源的情况下了解资源的情况
• 通过查看响应中的状态码，看看某个对象是否存在
• 通过查看首部，测试资源是否被修改了

HEAD 示例

3.3 PUT

• PUT 的语义就是让服务器用请求的主体部分来创建一个由所请求的 URL 命名的新文档，或者，如果那个 URL 已经存在的话，就用这个主体来替代它。

POST 示例

3.4 POST

• 通常用来给服务器输入数据的。

POST 实例

3.5 TRACE

• 客户端发起一个请求时，这个请求可能要穿过防火墙、代理、网关或其他一些应用程序。每个中间节点都可能会修改原始的 HTTP 请求。TRACE 方法允许客户端在最终将请求发送给服务器时，看看它变成什么样子。

TRACE 示例

3.6 OPTIONS

• OPTIONS 方法请求 Web 服务器告知其支持的各种功能。

OPTIONS 示例

3.7 DELETE

• 请求服务器删除请求 URL 所指定的资源。

DELETE 示例

3.8 扩展方法

• 扩展方法即 HTTP/1.1 规范中尚未定义的方法，以下是一些常见扩展方法的实例：

Web 发布扩展方法示例

四、状态码

4.1 100～199 （信息性状态码）

信息性状态码及原因短语

4.2 200～299 （成功状态码）

成功状态码和原因短语

4.3 300～399 （重定向状态码）

将请求重定向到新的位置 重定向为使用本地副本的请求 重定向状态码与原因短语 重定向状态码与原因短语

4.4 400～499 （客户端错误状态码）

客户端错误状态码及原因短语 客户端错误状态码及原因短语

4.5 500～599 （服务器错误状态码）

服务器错误状态码及原因短语 服务器错误状态码及原因短语

五、首部

5.1 通用首部

• 有些首部提供了与报文相关的最基本信息，它们被称为通用首部。请求报文和响应报文都有。

通用的信息性首部 通用缓存首部

5.2 请求首部

• 请求首部是只在请求报文中有意义的首部。用于说明是谁或什么在发送请求、请求源自何处，或者客户端的喜好及能力。服务器可以根据请求首部给出的客户端信息，试着为客户端提供更好的响应。

请求的信息性首部

• Accept 首部为客户端提供了一种将其支持类型告知服务器的方式：

Accept 首部

• 条件请求首部：有时客户端希望为请求加上某些限制。比如客户端已有一份文档副本，就希望在服务器上的文档跟客户端拥有的副本有所区别时，才请求服务器传输文档。

条件请求首部

• 安全请求首部：HTTP 本身就支持一种简单的机制，可以对请求进行质询/响应认证。这种机制要求客户端在获取特定的资源之前，先对自身进行认证，这样就可以使事务稍微安全一些。

安全请求首部

• 代理请求首部：

代理请求首部

5.3 响应首部

• 响应首部为客户端提供了一些额外信息，比如谁在发送响应、响应者的功能，甚至与响应相关的一些特殊指令。

响应的信息性首部

• 协商首部：如果资源有多种表示方法，比如服务器上有某文档的法语和德语译稿，HTTP/1.1 可以为服务器和客户端提供对资源进行协商的能力。

协商首部

• 安全响应首部：本质上就是 HTTP 的质询/响应认证机制的响应侧。

安全响应首部

5.4 实体首部

• 实体首部提供了有关实体及其内容的大量信息，从有关对象类型的信息，到能够对资源使用的各种有效的请求方法。

实体的信息性首部

• 内容首部：内容首部提供了对实体内容有关的特定信息，说明了其类型、尺寸以及处理它所需的其它有用信息。

内容首部

• 实体缓存首部：实体的缓存首部提供了与被缓存实体有关的信息。

实体缓存首部