前面介绍了URL是用于定位服务器上的资源。但是定位到资源后，通过什么样的方式、规定来让客户端和服务端进行交流呢？这就是本篇要介绍的HTTP报文。
HTTP 报文是在 HTTP 应用程序之间发送的数据块。这些数据块以一些文本形式的元信息（meta-information）开头。这些报文在客户端、服务器和代理之间流动。术语“流入”、“流出”、“上游”及“下游”都是用来描述报文方向的。一个示例如下图所示：
HTTP 报文会像河水一样流动。不管是请求报文还是响应报文，所有报文都会向下游（downstream）流动。所有报文的发送者都在接收者的上游（upstream）。如下图所示中，对请求报文来说，代理 1 位于代理 3 的上游，但对响应报文来说，它就位于代理 3 的下游 1。
一条HTTP报文一般由如下部分组成：对报文进行描述的起始行（start line）、包含属性的首部（header）块，以及可选的、包含数据的主体（body）部分。示例如图：
如上图所示，start line和header一般都有ASCII码组成，每行都由CRLF标识作为结束终止，但是有些程序也会用单个换行符作为结束标志。body部分另外两个组成部分不太一样，除了可以包含文本外，还可以包含一些二进制数据。
HTTP报文分为两类：请求报文和响应报文。两类报文的格式如下：
请求报文
<method> <request-URL> <version>
<headers>
<entity-body>
请求报文：
<version> <status> <reason-phrase>
<headers>
<entity-body>
每个部分简要介绍如下：
所有的 HTTP 报文都以一个起始行作为开始。分为请求行和向应行。
请求的起始行以方法作为开始，方法用来告知服务器需要做什么，HTTP规范中定义了常用的方法如下：
| 方 法 | 描 述 | 是否包含主体 |
|---|---|---|
| GET | 从服务器获取一份文档 | 否 |
| HEAD | 只从服务器获取文档的首部 | 否 |
| POST | 向服务器发送需要处理的数据 | 是 |
| PUT | 将请求的主体部分存储在服务器上 | 是 |
| TRACE | 对可能经过代理服务器传送到服务器上去的报文进行追踪 | 否 |
| OPTIONS | 决定可以在服务器上执行哪些方法 | 否 |
| DELETE | 从服务器上删除一份文档 | 否 |
除了这些方法外，我们还可以自定义一些扩展方法。
方法是用来告诉服务器做什么事情的，状态码则用来告诉客户端，发生了什么事情。状态码位于响应行中，如：HTTP/1.0 200 OK中，200即为状态码。HTTP中状态码分类如下：
| 整体范围 | 已定义范围 | 分 类 |
|---|---|---|
| 100～199 | 100～101 | 信息提示 |
| 200～299 | 200～206 | 成功 |
| 300～399 | 300～305 | 重定向 |
| 400～499 | 400～415 | 客户端错误 |
| 500～599 | 500～505 | 服务器错误 |
常见状态码如下：
| 状 态 码 | 原因短语 | 含 义 |
|---|---|---|
| 200 | OK | 成功。请求的所有数据都在响应主体中 |
| 401 | Unauthorized（未授权） | 需要输入用户名和密码 |
| 404 | Not Found（未找到） | 服务器无法找到所请求URL对应的资源 |
原因短语是响应起始行中的最后一个组件。它为状态码提供了文本形式的解释。比如，在行 HTTP/1.0 200 OK 中，OK 就是原因短语。
版本号会以 HTTP/x.y 的形式出现在请求和响应报文的起始行中。版本号说明了应用程序支持的最高 HTTP 版本。
有个注意的地方，版本号不会被当作小数来处理。版本中的每个数字（比如 HTTP/1.0 中的 1 和 0）都会被当作一个单独的数字来处理。比如，HTTP/2.22 就比 HTTP/2.3 的版本要高，因为 22 比 3 大。
前面介绍了请求和响应的第一行数据——起始行，接下来介绍首部。
HTTP 首部字段向请求和响应报文中添加了一些附加信息。本质上来说，它们只是一些键值对的列表。首部一般分为以下几类：通用首部、请求首部、响应首部、实体首部、扩展首部。
每个 HTTP 首部都有一种简单的语法：名字后面跟着冒号（ ：），然后跟上可选的空格，再跟上字段值，最后是一个 CRLF。
常见首部示例如下：
| 首部实例 | 描 述 |
|---|---|
| Date:Tue,3Oct 1997 02:16:03 GMT | 服务器产生响应的日期 |
| Content-length:15040 | 实体的主体部分包含了15 040字节的数据 |
| Content-type:image/gif | 实体的主体部分是一个GIF图片 |
| Accept: image/gif, image/jpeg, text/html | 客户端可以接收GIF图片和JPEG图片以及HTML |
首部一个键可以对应多个值，如果出现此种情况，为了提高可读性，多出来的行每行前面至少要有一个空格或制表符，如：
HTTP/1.0 200 OK
Content-Type: image/gif
Content-Length: 8572
Server: Test Server
Version 1.0
HTTP 报文的第三部分是可选的实体主体部分。实体的主体是 HTTP 报文的负荷。就是 HTTP 要传输的内容。
HTTP 报文可以承载很多类型的数字数据：图片、视频、HTML 文档、软件应用程序、信用卡事务、电子邮件等。
上面我们也提到过方法，现在对方法进行一个详细的说明。
HTTP1.1要求，每台服务器必须要实现GET和HEAD方法，其他方法可以选择实现，也可以选择不实现。同时HEAD和GET也被称为安全方法，因为这两个方法不会对请求的资源产生任何动作。
GET 是最常用的方法。通常用于请求服务器发送某个资源。HTTP/1.1 要求服务器实现此方法。一个示例如下：
HEAD 方法与 GET 方法的行为很类似，但服务器在响应中只返回首部。使用HEAD方法，可以达到如下效果：
与 GET 从服务器读取文档相反，PUT 方法会向服务器写入文档。PUT方法会让服务器创建一个所请求URL命名的新文档，如果该文档已经存在，则会更新。
一个PUT请求示例如下：
POST 方法起初是用来向服务器输入数据的 。实际上，通常会用它来支持 HTML 的表单。这里注意其与PUT方法的区别是POST仅仅是用来给服务器发送数据，至于数据怎么处理完全由服务器自己决定，而PUT方法是让服务器存储数据的。
客户端发起一个请求时，这个请求可能要穿过防火墙、代理、网关或其他一些应用程序。每个中间节点都可能会修改原始的 HTTP 请求。TRACE 方法允许客户端在最终将请求发送给服务器时，看看它变成了什么样子。其一般用于诊断请求过程中是否被修改或者毁坏。TRACE 请求中不能带有实体的主体部分。
一个TRACE请求如下：
OPTIONS 方法请求 Web 服务器告知其支持的各种功能。可以询问服务器通常支持哪些方法，或者对某些特殊资源支持哪些方法。
顾名思义，DELETE 方法所做的事情就是请服务器删除请求 URL 所指定的资源。但是，客户端应用程序无法保证删除操作一定会被执行。因为 HTTP 规范允许服务器在不通知客户端的情况下撤销请求。
HTTP 被设计成字段可扩展的，这样新的特性就不会使老的软件失效了。扩展方法指的就是没有在 HTTP/1.1 规范中定义的方法。服务器会为它所管理的资源实现一些 HTTP 服务，这些方法为开发者提供了一种扩展这些 HTTP 服务能力的手段。
状态码总体被分为5大类，之前已经介绍过了。这里我们针对没类做一些介绍。
| 状 态 码 | 原因短语 | 含 义 |
|---|---|---|
| 100 | Continue | 说明收到了请求的初始部分，请客户端继续。发送了这个状态码之后，服务器在收到请求之后必须进行响应。更多信息请参见附录C中的Expect 首部介绍 |
| 101 | Switching Protocols | 说明服务器正在根据客户端的指定，将协议切换成Update 首部所列的协议 |
客户端发起请求时，这些请求通常都是成功的。服务器有一组用来表示成功的状态码。
| 状态码 | 原因短语 | 含 义 |
|---|---|---|
| 200 | OK | 请求没问题，实体的主体部分包含了所请求的资源 |
| 201 | Created | 用于创建服务器对象的请求（比如，PUT）。响应的实体主体部分中应该包含各种引用了已创建的资源的URL，Location首部包含的则是最具体的引用。服务器必须在发送这个状态码之前创建好对象 |
| 202 | Accepted | 请求已被接受，但服务器还未对其执行任何动作。不能保证服务器会完成这个请求；这只是意味着接受请求时，它看起来是有效的。 服务器应该在实体的主体部分包含对请求状态的描述，或许还应该有对请求完成时间的估计（或者包含一个指针，指向可以获取此信息的位置） |
| 203 | Non-Authoritative Information | 实体首部包含的信息不是来自于源端服务器，而是来自资源的一份副本。如果中间节点上有一份资源副本，但无法或者没有对它所发送的与资源有关的元信息（首部）进行验证，就会出现这种情况。 这种响应码并不是非用不可的；如果实体首部来自源端服务器，响应为200状态的应用程序就可以将其作为一种可选项使用 |
| 204 | No Content | 响应报文中包含若干首部和一个状态行，但没有实体的主体部分。主要用于在浏览器不转为显示新文档的情况下，对其进行更新（比如刷新一个表单页面） |
| 205 | Reset Content | 另一个主要用于浏览器的代码。负责告知浏览器清除当前页面中的所有HTML 表单元素 |
| 206 | Partial Content | 成功执行了一个部分或Range（范围）请求。稍后我们会看到，客户端可以通过一些特殊的首部来获取部分或某个范围内的文档——这个状态码就说明范围请求成功了。 206响应中必须包含Content-Range、Date以及ETag或Content-Location 首部 |
重定向状态码要么告知客户端使用替代位置来访问他们所感兴趣的资源，要么就提供一个替代的响应而不是资源的内容。如果资源已被移动，可发送一个重定向状态码和一个可选的 Location 首部来告知客户端资源已被移走，以及现在可以在哪里找到它。请求示例如下：
常见的重定向状态码如下：
| 状态码 | 原因短语 | 含 义 |
|---|---|---|
| 300 | Multiple Choices | 客户端请求一个实际指向多个资源的URL时会返回这个状态码，比如服务器上有某个HTML文档的英语和法语版本。返回这个代码时会带有一个选项列表；这样用户就可以选择他希望使用的那一项了。有多个版本可用时，客户端需要沟通解决。服务器可以在Location 首部包含首选URL |
| 301 | Moved Permanently | 在请求的URL已被移除时使用。响应的Location 首部中应该包含资源现在所处的URL |
| 302 | Found | 与301状态码类似；但是，客户端应该使用Location 首部给出的URL来临时定位资源。将来的请求仍应使用老的URL |
| 303 | See Other | 告知客户端应该用另一个URL来获取资源。新的URL位于响应报文的 Location 首部。其主要目的是允许POST请求的响应将客户端定向到某个资源上去 |
| 304 | Not Modified | 客户端可以通过所包含的请求首部，使其请求变成有条件的。更多有关条件首部的内容请参见第3章。如果客户端发起了一个条件GET请求，而最近资源未被修改的话，就可以用这个状态码来说明资源未被修改。带有这个状态码的响应不应该包含实体的主体部分 |
| 305 | Use Proxy | 用来说明必须通过一个代理来访问资源；代理的位置由Location 首部给出。很重要的一点是，客户端是相对某个特定资源来解析这条响应的，不能假定所有请求，甚至所有对持有所请求资源的服务器的请求都通过这个代理进行。如果客户端错误地让代理介入了某条请求，可能会引发破坏性的行为，而且会造成安全漏洞 |
| 306 | （未使用） | 当前未使用 |
| 307 | Temporary Redirect | 与301状态码类似；但客户端应该使用Location 首部给出的URL来临时定位资源。将来的请求应该使用老的URL |
其中302，303，307的区别如下：
有时客户端会发送一些服务器无法处理的东西，比如格式错误的请求报文，这时服务器就会返回400系列错误码告知客户端。
常用错误码如下：
| 状态码 | 原因短语 | 含 义 |
|---|---|---|
| 400 | Bad Request | 用于告知客户端它发送了一个错误的请求 |
| 401 | Unauthorized | 与适当的首部一同返回，在这些首部中请求客户端在获取对资源的访问权之前，对自己进行认证。 |
| 402 | Payment Required | 现在这个状态码还未使用，但已经被保留，以作未来之用 |
| 403 | Forbidden | 用于说明请求被服务器拒绝了。如果服务器想说明为什么拒绝请求，可以包含实体的主体部分来对原因进行描述。但这个状态码通常是在服务器不想说明拒绝原因的时候使用的 |
| 404 | Not Found | 用于说明服务器无法找到所请求的URL。通常会包含一个实体，以便客户端应用程序显示给用户看 |
| 405 | Method Not Allowed | 发起的请求中带有所请求的URL不支持的方法时，使用此状态码。应该在响应中包含Allow首部，以告知客户端对所请求的资源可以使用哪些方法。 |
| 406 | Not Acceptable | 客户端可以指定参数来说明它们愿意接收什么类型的实体。服务器没有与客户端可接受的URL相匹配的资源时，使用此代码。通常，服务器会包含一些首部，以便客户端弄清楚为什么请求无法满足。更多信息请参见第17章 |
| 407 | Proxy Authentication Required | 与401状态码类似，但用于要求对资源进行认证的代理服务器 |
| 408 | Request Timeout | 如果客户端完成请求所花的时间太长，服务器可以回送此状态码，并关闭连接。超时时长随服务器的不同有所不同，但通常对所有的合法请求来说，都是够长的 |
| 409 | Conflict | 用于说明请求可能在资源上引发的一些冲突。服务器担心请求会引发冲突时，可以发送此状态码。响应中应该包含描述冲突的主体 |
| 410 | Gone | 与404类似，只是服务器曾经拥有过此资源。主要用于Web站点的维护，这样服务器的管理者就可以在资源被移除的情况下通知客户端了 |
| 411 | Length Required | 服务器要求在请求报文中包含Content-Length首部时使用。 |
| 412 | Precondition Failed | 客户端发起了条件请求，且其中一个条件失败了的时候使用。客户端包含了Expect首部时发起的就是条件请求。 |
| 413 | Request Entity Too Large | 客户端发送的实体主体部分比服务器能够或者希望处理的要大时，使用此状态码 |
| 414 | Request URI Too Long | 客户端所发请求中的请求URL比服务器能够或者希望处理的要长时，使用此状态码 |
| 415 | Unsupported Media Type | 服务器无法理解或无法支持客户端所发实体的内容类型时，使用此状态码 |
| 416 | Requested Range Not Satisfiable | 请求报文所请求的是指定资源的某个范围，而此范围无效或无法满足时，使用此状态码 |
| 417 | Expectation Failed | 请求的Expect请求首部包含了一个期望，但服务器无法满足此期望时，使用此状态码。如果代理或其他中间应用程序有确切证据说明源端服务器会为某请求产生一个失败的期望，就可以发送这个响应状 |
如果客户端发出了正确的请求，但是服务器由于自身的原因无法正确处理，或者内部出现错误，这个时候就会返回该系列错误码用于说明具体是什么错误。
常见的错误码如下：
| 状态码 | 原因短语 | 含 义 |
|---|---|---|
| 500 | Internal Server Error | 服务器遇到一个妨碍它为请求提供服务的错误时，使用此状态码 |
| 501 | Not Implemented | 客户端发起的请求超出服务器的能力范围（比如，使用了服务器不支持的请求方法）时，使用此状态码 |
| 502 | Bad Gateway | 作为代理或网关使用的服务器从请求响应链的下一条链路上收到了一条伪响应（比如，它无法连接到其父网关）时，使用此状态码 |
| 503 | Service Unavailable | 用来说明服务器现在无法为请求提供服务，但将来可以。如果服务器知道什么时候资源会变为可用的，可以在响应中包含一个Retry-After首部。 |
| 504 | Gateway Timeout | 与状态码408类似，只是这里的响应来自一个网关或代理，它们在等待另一服务器对其请求进行响应时超时了 |
| 505 | HTTP Version Not Supported | 服务器收到的请求使用了它无法或不愿支持的协议版本时，使用此状态码。有些服务器应用程序会选择不支持协议的早期 |
前面概述的时候，已经大致说了Header可以分为几类，下面就针对没类再进行一些说明。
所谓通用首部，就是不区分是请求首部还是响应首部，都可以使用的首部，一般用于提供报文的基本信息。
常用的通用首部如下：
| 首 部 | 描 述 |
|---|---|
| Connection | 允许客户端和服务器指定与请求/响应连接有关的选项 |
| Date | 提供日期和时间标志，说明报文是什么时间创建的 |
| MIME-Version | 给出了发送端使用的MIME版本 |
| Trailer | 如果报文采用了分块传输编码（chunked transfer encoding）方式，就可以用这个首部列出位于报文拖挂（trailer）部分的首部集合2 |
| Transfer-Encoding | 告知接收端为了保证报文的可靠传输，对报文采用了什么编码方式 |
| Update | 给出了发送端可能想要“升级”使用的新版本或协议 |
| Via | 显示了报文经过的中间节点（代理、网关） |
| Cache-Control | 用于随报文传送缓存指示 |
| Pragma | 另一种随报文传送指示的方式，但并不专用于缓存 |
请求首部是指只能用在请求当中的首部信息。常用请求首部如下：
| 首 部 | 描 述 |
|---|---|
| Client-IP4 | 提供了运行客户端的机器的IP地址 |
| From | 提供了客户端用户的E-mail地址 |
| Host | 给出了接收请求的服务器的主机名和端口号 |
| Referer | 提供了包含当前请求URI的文档的URL |
| UA-Color | 提供了与客户端显示器的显示颜色有关的信息 |
| UA-CPU | 给出了客户端CPU的类型或制造商 |
| UA-Disp | 提供了与客户端显示器（屏幕）能力有关的信息 |
| UA-OS | 给出了运行在客户端机器上的操作系统名称及版本 |
| UA-Pixels | 提供了客户端显示器的像素信息 |
| User-Agent | 将发起请求的应用程序名称告知服务器 |
如果我们再细分一下，请求首部一般分为下面几种类型：
该首部告诉服务器客户端可以接收哪些条件的响应数据，具体如下：
| 首 部 | 描 述 |
|---|---|
| Accept | 告诉服务器能够发送哪些媒体类型 |
| Accept-Charset | 告诉服务器能够发送哪些字符集 |
| Accept-Encoding | 告诉服务器能够发送哪些编码方式 |
| Accept-Language | 告诉服务器能够发送哪些语言 |
| TE7 | 告诉服务器可以使用哪些扩展传输编码 |
客户端在某些情况下会对请求加上一部分条件限制，比如我们已经在本地缓存了一份文档的数据，通过 If-Modified-Since 条件首部就可以判断我们的缓存是否还有效，是否需要重新从服务器获取新的文档。常见的条件首部如下：
| 首 部 | 描 述 |
|---|---|
| Expect | 允许客户端列出某请求所要求的服务器行为 |
| If-Match | 如果实体标记与文档当前的实体标记相匹配，就获取这份文档 |
| If-Modified-Since | 除非在某个指定的日期之后资源被修改过，否则就限制这个请求 |
| If-None-Match | 如果提供的实体标记与当前文档的实体标记不相符，就获取文档 |
| If-Range | 允许对文档的某个范围进行条件请求 |
| If-Unmodified-Since | 除非在某个指定日期之后资源没有被修改过，否则就限制这个请求 |
| Range | 如果服务器支持范围请求，就请求资源的指定范围9 |
HTTP 本身就支持一种简单的机制，可以对请求进行质询 / 响应认证。这种机制要求客户端在获取特定的资源之前，先对自身进行认证，这样就可以使事务稍微安全一些。常用的安全首部如下：
| 首 部 | 描 述 |
|---|---|
| Authorization | 包含了客户端提供给服务器，以便对其自身进行认证的数据 |
| Cookie | 客户端用它向服务器传送一个令牌——它并不是真正的安全首部，但确实隐含了安全功能 |
| Cookie2 | 用来说明请求端支持的cookie版本 |
随着因特网上代理的普遍应用，人们定义了几个首部来协助其更好地工作。
| 首 部 | 描 述 |
|---|---|
| Max-Forward | 在通往源端服务器的路径上，将请求转发给其他代理或网关的最大次数——与TRACE方法一同使用 |
| Proxy-Authorization | 与Authorization 首部相同，但这个首部是在与代理进行认证时使用的 |
| Proxy-Connection | 与Connection 首部相同，但这个首部是在与代理建立连接时使用的 |
响应首部是指用在响应的首部信息，常用的响应首部如下：
| 首 部 | 描 述 |
|---|---|
| Age | （从最初创建开始）响应持续时间 |
| Public | 服务器为其资源支持的请求方法列表 |
| Retry-After | 如果资源不可用的话，在此日期或时间重试 |
| Server | 服务器应用程序软件的名称和版本 |
| Title | 对HTML文档来说，就是HTML文档的源端给出的标题 |
| Warning | 比原因短语中更详细一些的警告报文 |
同请求首部一样，响应首部也可进一步细分。
协商首部是用于一些可协商资源的情况。如：同样一份稳定，有中文，英文等几种语言。这个时候，就可以通过协商首部确定是哪种语言的资源。
| 首 部 | 描 述 |
|---|---|
| Accept-Ranges | 对此资源来说，服务器可接受的范围类型 |
| Vary | 服务器查看的其他首部的列表，可能会使响应发生变化；也就是说，这是一个首部列表，服务器会根据这些首部的内容挑选出最适合的资源版本发送给客户端 |
其意义同安全请求首部，只是用于响应而已，常用的首部如下：
| 首 部 | 描 述 |
|---|---|
| Proxy-Authenticate | 来自代理的对客户端的质询列表 |
| Set-Cookie | 不是真正的安全首部，但隐含有安全功能；可以在客户端设置一个令牌，以便服务器对客户端进行标识 |
| Set-Cookie2 | 与Set-Cookie 类似，RFC 2965 Cookie定义； |
| WWW-Authenticate | 来自服务器的对客户端的质询列表 |
有部分首部是用于描述实体(body)部分数据的信息的，这个部分首部被称为实体首部，由于请求和响应报文都可携带实体数据，所以该部分首部并不一定区分是请求首部还是响应首部。
该部分内容主要用于描述实体内容的信息，常见的如下表：
| 首 部 | 描 述 |
|---|---|
| Content-Base | 解析主体中的相对URL时使用的基础URL |
| Content-Encoding | 对主体执行的任意编码方式 |
| Content-Language | 理解主体时最适宜使用的自然语言 |
| Content-Length | 主体的长度或尺寸 |
| Content-Location | 资源实际所处的位置 |
| Content-MD5 | 主体的MD5校验和 |
| Content-Range | 在整个资源中此实体表示的字节范围 |
| Content-Type | 这个主体的对象类型 |
该部分首部主要用于描述缓存相关信息，常见如下：
| 首 部 | 描 述 |
|---|---|
| ETag | 与此实体相关的实体标记17 |
| Expires | 实体不再有效，要从原始的源端再次获取此实体的日期和时间 |
| Last-Modified | 这个实体最后一次被修改的日期和时间 |
到这里，HTTP报文的相关简要介绍都这就结束了，本篇只是对整体进行了简要介绍。其中有些重要的内容后续章节会进行展开详细说明。