http报文详解

http报文

http报文是http协议的核心所在，http客户端和http服务端正是通过交换http报文进行通信的。http报文以一些文本形式的元信息（meta-information）开头，这些信息描述了报文的内容及含义，后面跟着可选的数据部分。

http报文总是向下游流动的。对于客户端而言，代理和服务器就是它的下游，请求报文会流向代理，然后在流向服务器；对于服务器而言，代理和客户端就是它的下游，报文会流向代理和客户端。如图所示：

报文组成部分

http报文由三个部分组成：对报文进行描述的起始行（start line）、包含属性的首部（header）块，以及可选的、包含数据的主体（body）部分。

起始行和首部就是由行分隔的 ASCII 文本。每行都以一个由两个字符组成的行终止序列作为结束，其中包括一个回车符（ASCII 码 13）和一个换行符（ASCII 码 10）。这个行终止序列可以写做 CRLF。需要指出的是，尽管 HTTP 规范中说明应该用CRLF 来表示行终止，但稳健的应用程序也应该接受单个换行符作为行的终止。有些老的，或不完整的 HTTP 应用程序并不总是既发送回车符，又发送换行符。

报文的主体（或者就称为主体）是一个可选的数据块。与起始行和首部不同的是，主体中可以包含文本或二进制数据，也可以为空。

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

请求报文格式

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

响应报文格式

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

请求报文和响应报文的格式基本一致，它们只有起始行的语法有所不同。下面对请求报文和响应报文中各部分做一个描述。

起始行

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

• 请求行
  请求行包括了方法，url，以及http协议版本。这三个字段之间由空格符分隔。例如：

    POST /api/post HTTP/1.1
  

  这表示请求方法为 POST，请求 URL 为 /api/post，http协议的版本为1.1；请求方法用来告知服务器要做些什么，url是用来定位资源的位置，http版本将自己所遵循的协议版本告知对方，以便互相了解对方的能力和报文格式。

• 响应行

  响应行包括了http协议版本，响应状态码以及原因短语。这三个字段之间由空格符分隔，例如：

    HTTP/1.1 200 OK
  

  这表示http版本是1.1，响应状态码是200，原因短语是OK。响应状态码的作用是告诉客户端，发生了什么事情，而原因短语是为了更便于人们理解，所有的处理过程使用的都是响应状态码。

在http1.0之前，并不要求在请求行和响应行中包含http协议版本，现在应该没有web服务使用http1.0之前的协议了，我们平时几乎也见不到http1.0协议。

在起始行中，http版本形式是：

HTTP/<major>.<minor>

其中主要版本号（major）和次要版本号（minor）都是整数。现阶段主要使用的是HTTP/1.0，HTTP/1.1，HTTP/2
注意，版本号不会被当作小数来处理。版本中的每个数字（比如 HTTP/1.0 中的 1和 0）都会被当作一个单独的数字来处理。因此，在比较 HTTP 版本时，每个数字都必须单独进行比较，以便确定哪个版本更高。比如，HTTP/2.22 就比 HTTP/2.3 的版本要高，因为 22 比 3 大。

方法

方法用来告诉服务器执行什么动作，主要是http的设计者们把一切都抽象为资源，而方法就是对资源执行的动作。如果一台服务器要与 HTTP 1.1 兼容，那么只要为其资源实现 GET 方法和 HEAD 方法就可以了。http提供了一些方法，即使服务器实现了所有这些方法，某些方法的使用很可能也是受限的，这些是可以通过在服务器的配置中进行设置的。例如有的服务器只允许get，head，options以及post请求。

另外就是HTTP方法在报文中必须是大写的。

安全方法

HTTP 定义了一组被称为安全方法的方法。GET 方法和 HEAD 方法都被认为是安全的，这就意味着使用 GET 或 HEAD 方法的 HTTP 请求不会在服务器上产生修改资源的操作。但是这并不是一定的，因为web开发者也可以让GET方法修改资源，这是由开发者决定的。通常大多数开发者都是开发RESTful风格的api，GET方法不会产生修改资源的效果。

HTTP常见方法表

下图是trace请求的示例。

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

状态码

状态码为客户端提供了一种理解事务处理结果的便捷方式。尽管并没有实际的规范对原因短语的确切文本进行说明。HTTP 状态码被分成了五大类。

100～199——信息性状态码

HTTP/1.1 向协议中引入了信息性状态码，并已定义两个状态码。

100 Continue 状态码尤其让人糊涂。它的目的是对这样的情况进行优化：HTTP 客户端应用程序有一个实体的主体部分要发送给服务器，但希望在发送之前查看一下服务器是否会接受这个实体。

如果客户端在向服务器发送一个实体，并且愿意在发送实体之前等待 100 Continue响应，那么，客户端就要发送一个携带了值为 100 Continue 的 Expect 请求首部如果客户端没有发送实体，就不应该发送 100 Continue Expect 首部，因为这样会使服务器误以为客户端要发送一个实体。

从很多方面来看，100 Continue 都是一种优化。客户端应用程序只有在避免向服务器发送一个服务器无法处理或使用的大实体时，才应该使用 100 Continue。

发送了值为 100 Continue 的 Expect 首部的客户端不应该永远在那儿等待服务器发送 100 Continue 响应。超时一定时间之后，客户端应该直接将实体发送出去。

如果服务器收到了一条带有值为 100 Continue 的 Expect 首部的请求，它会用 100 Continue 响应或一条错误码来进行响应。服务器永远也不应该向没有发送 100 Continue 期望的客户端发送 100 Continue 状态码。如果出于某种原因，服务器在有机会发送 100 Continue 响应之前就收到了部分（或全部）的实体，就说明客户端已经决定继续发送数据了，这样，服务器就不需要发送这个状态码了。但服务器读完请求之后，还是应该为请求发送一个最终状态码（它可以跳过 100 Continue 状态）。

200～299——成功状态码

客户端发起请求时，这些请求通常都是成功的。服务器有一组用来表示成功的状态码，分别对应于不同类型的请求。下面是已定义的成功状态码。

300～399——重定向状态码

重定向状态码要么告知客户端使用替代位置来访问他们所感兴趣的资源，要么就提供一个替代的响应而不是资源的内容。如果资源已被移动，可发送一个重定向状态码和一个可选的 Location 首部来告知客户端资源已被移走，以及现在可以在哪里找到它。这样，浏览器就可以在不打扰使用者的情况下，透明地转入新的位置了。

可以通过某些重定向状态码对资源的应用程序本地副本与源端服务器上的资源进行验证。比如，HTTP 应用程序可以查看其资源的本地副本是否仍然是最新的，或者在源端服务器上资源是否被修改过。下图显示了一个这样的例子。客户端发送了一个特殊的 If-Modified-Since 首部，说明只读取 1997 年 10 月之后修改过的文档。这个日期之后，此文档并未被修改过，因此，服务器回送了一个 304 状态码，而不是文档的内容。

在对那些包含了重定向状态码的非 HEAD 请求进行响应时，最好要包含一个实体，并在实体中包含描述信息和指向（多个）重定向 URL 的链接。下表列出了已定义的重定向状态码。

302、303 和 307 状态码之间存在一些交叉。这些状态码的用法有着细微的差别，大部分差别都源于 HTTP/1.0 和 HTTP/1.1 应用程序对这些状态码处理方式的不同。

当 HTTP/1.0 客户端发起一个 POST 请求，并在响应中收到 302 重定向状态码时，它会接受 Location 首部的重定向 URL，并向那个 URL 发起一个 GET 请求（而不会像原始请求中那样发起 POST 请求）。

HTTP/1.0 服务器希望 HTTP/1.0 客户端这么做——如果 HTTP/1.0 服务器收到来自HTTP/1.0 客户端的 POST 请求之后发送了 302 状态码，服务器就期望客户端能够接受重定向 URL，并向重定向的 URL 发送一个 GET 请求。

问题出在 HTTP/1.1。HTTP/1.1 规范使用 303 状态码来实现同样的行为（服务器发送 303 状态码来重定向客户端的 POST 请求，在它后面跟上一个 GET 请求）。为了避开这个问题，HTTP/1.1 规范指出，对于 HTTP/1.1 客户端，用 307 状态码取代 302 状态码来进行临时重定向。这样服务器就可以将 302 状态码保留起来，为HTTP/1.0 客户端使用了。这样一来，服务器要选择适当的重定向状态码放入重定向响应中发送，就需要查看客户端的 HTTP 版本了。

400～499——客户端错误状态码

有时客户端会发送一些服务器无法处理的东西，比如格式错误的请求报文，或者最常见的是，请求一个不存在的 URL。

500～599——服务器错误状态码

有时客户端发送了一条有效请求，服务器自身却出错了。这可能是客户端碰上了服务器的缺陷，或者服务器上的子元素，比如某个网关资源，出了错。

URL

关于URL，请阅读这篇URL语法，编码以及未来的可能性文章。这里有对URL相关内容非常详细的描述。

HTTP版本

在前文介绍过了http的版本的形式，但是对于现在主要使用的两个版本http1.1和http2，我们并没有详细介绍其连接管理，特性这部分内容，关于http1.1和http2，请阅读文章http1.1和http2

HTTP头（首部）

HTTP 首部字段向请求和响应报文中添加了一些附加信息。本质上来说，它们只是一些键值对的列表。

每个 HTTP 首部都有一种简单的语法：名字后面跟着冒号（ ：），然后跟上可选的空格，再跟上字段值，最后是一个 CRLF。（非标准的http报文后面可能只包含\n，而不包含\r）

首部和方法配合工作，共同决定了客户端和服务器能做什么事情。在请求和响应报文中都可以用首部来提供信息，有些首部是某种报文专用的，有些首部则更通用一些。可以将首部分为五个主要的类型。

通用首部

这些是客户端和服务器都可以使用的通用首部。可以在客户端、服务器和其他应用程序之间提供一些非常有用的通用功能。

从技术角度来看，Pragma 是一种请求首部。从未被指定用于响应首部。由于经常被错误地用于响应首部，很多客户端和代理都会将 Pragma 解释为响应首部，但其确切语义并未得到很好地定义。任何情况下 Cache-Control 的使用都优于 Pragma。

请求首部

从名字中就可以看出，请求首部是请求报文特有的。它们为服务器提供了一些额外信息，比如客户端希望接收什么类型的数据。

RFC 2616 没有定义 Client-IP 和 UA-* 首部，但很多 HTTP 客户端应用程序都实现了这两个首部。

Accept 相关的首部为客户端提供了一种将其喜好和能力告知服务器的方式，包括它们想要什么，可以使用什么，以及最重要的，它们不想要什么。这样，服务器就可以根据这些额外信息，对要发送的内容做出更明智的决定。Accept 首部会使连接的两端都受益。客户端会得到它们想要的内容，服务器则不会浪费其时间和带宽来发送客户端无法使用的东西。

有时客户端希望为请求加上某些限制。比如，如果客户端已经有了一份文档副本，就希望只在服务器上的文档与客户端拥有的副本有所区别时，才请求服务器传输文档。通过条件请求首部，客户端就可以为请求加上这种限制，要求服务器在对请求进行响应之前，确保某个条件为真。

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

响应首部

响应报文有自己的响应首部集。响应首部为客户端提供了一些额外信息，比如谁在发送响应、响应者的功能，甚至与响应相关的一些特殊指令。这些首部有助于客户端处理响应，并在将来发起更好的请求。

实体首部

实体首部指的是用于应对实体主体部分的首部。比如，可以用实体首部来说明实体主体部分的数据类型。实体首部提供了有关实体及其内容的大量信息，从有关对象类型的信息，到能够对资源使用的各种有效的请求方法。总之，实体首部可以告知报文的接收者它在对什么进行处理。

扩展首部

扩展首部是非标准的首部，由应用程序开发者创建，但还未添加到已批准的HTTP 规范中去。即使不知道这些扩展首部的含义，HTTP 程序也要接受它们并对其进行转发。

HTTP Body （主体部分）

HTTP 报文的第三部分是可选的实体主体部分。实体的主体是 HTTP 报文的负荷。就是 HTTP 要传输的内容。最初的HTTP报文只能被客户程序解释为超文本标记语言HTML 文档。后来HTTP通过给每种Web 传输的对象都打上了名为 MIME 类型（MIME type）的数据格式标签的方式来承载非常多的数据类型。

最初设计 MIME（Multipurpose Internet Mail Extension，多用途因特网邮件扩展）是为了解决在不同的电子邮件系统之间搬移报文时存在的问题。MIME 在电子邮件系统中工作得非常好，因此 HTTP 也采纳了它，用它来描述并标记多媒体内容。现在的HTTP 报文可以承载很多类型的数字数据：图片、视频、HTML 文档、软件应用程序、信用卡事务、电子邮件等。

参考资料

《HTTP权威指南》