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 中的 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。