《HTTP权威指南》学习笔记-HTTP报文

上一篇文章写了HTTP协议中的基本概念和URL，这一篇要来讲一下HTTP协议中的报文本身。如果说HTTP是Internet的信使，那么HTTP报文就是它用来搬东西的包裹了。本文包含以下内容：

1. HTTP报文的组成部分
2. HTTP报文的语法结构
3. HTTP方法
4. HTTP状态码
5. HTTP首部（Header）详解
6. 自己的一些读后的总结和感悟

HTTP报文的语法

HTTP是基于请求/响应模式的通信协议，所有的HTTP报文可以分为请求报文和响应报文。请求报文会向Web服务器请求一个动作，响应报文会将请求结果返回给客户端。

语法结构

请求报文和响应报文的基本结构非常类似，下面是请求报文的语法结构：

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

下面是响应报文的语法结构：

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

可以看出，请求报文和响应报文的语法仅仅在起始行（第一行）处有所不同。下面对报文的各个部分做简要描述。

方法（method）：表示客户端对资源执行的动作，是一个单独的动词，比如GET、POST等。
请求资源的URL（request-url）：表示请求的资源的URL，关于URL的知识已经在上一篇文章中介绍了。
协议版本（version）：表示所使用的HTTP的协议版本，其格式为：HTTP/.，其中major表示主版本号，minor表示次版本号。
状态码（status-code）：表示请求过程中所发生的情况，是一组三位数的数字。关于状态码会在接下来的内容介绍。
原因短语（reason-phrase）：状态码的可读版本，是对状态码的解释，对人类来说是可读的。
首部（header）：表示请求或响应中的附加信息，可以有零个或多个首部，每个首部项都是形如name: value的字符串，每个首部项后面都以CRLF（回车+换行）结束。
实体的主体部分（entity-body）：包含任意格式的数据块，是Web应用的主体内容。

HTTP报文的组成部分

HTTP报文包括请求报文和响应报文，由起始行（start line）、首部（header）和主体(body)三个部分组成，其中起始行和首部是必有的，主体部分是可选的。

起始行(start line)

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

请求起始行
请求报文请求对服务器中的资源进行一些操作，包含请求方法，请求URL，在有些版本的协议中还需要加入HTTP协议的版本。一个典型的请求报文的起始行如下：

GET /test/hi-there.txt HTTP/1.1

注意，URL部分并不包含主机信息，不是完整的路径，而是具体服务器上的资源路径。主机（host）的信息会包含到首部中，首部会在接下来的内容中介绍。

响应起始行
响应报文承载着响应状态信息和操作产生的结果数据，并返回给客户端。响应起始行包含着HTTP版本、数字状态码以及描述操作状态的文本形式的原因短语，每一部分之间用空格分隔。一个典型的响应报文的起始行如下：

HTTP/1.1 200 OK

首部(header)

首部是向请求或响应报文中添加的附加信息，本质上来说，是一些key:value列表。下面列出了一些平常常见的首部。

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8Accept-Encoding:gzip, deflate, sdchAccept-Language:zh-CN,zh;q=0.8,en;q=0.6,ja;q=0.4,zh-TW;q=0.2Cache-Control:max-age=0Host:www.csdn.netUser-Agent:Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36

由于首部全部都是文本，所以首部是可扩展的，只要服务端支持即可。首部字段可以分成下面几类：

• 通用首部：可以同时用于请求和响应报文，比如Date首部。
• 请求首部
• 响应首部
• 实体首部
• 扩展首部

首部内容是HTTP中的重点内容，在实际开发过程中需要时常与之接触，详细内容将接下来的单独介绍。

主体(body)

主体是HTTP报文实际负载的内容，具体来说，就是应用程序数据。Web开发者要做工作就是编写这部分内容。主体类型非常丰富，可以是：图片、视频、HTML文档、电子邮件等。所以HTTP协议为什么将超文本传输协议，就是因为其负载的内容并不局限与文本。主体的类型有上层开发者负责，HTTP协议对它并没有做很多约束和限制。

HTTP方法

方法告知服务器要做什么操作，位于请求报文起始行的开始位置。HTTP协议中规定的主要方法有：

• GET：最常用的方法，用户请求服务器上的某个资源。
• HEAD：与GET方法的行为很类似，但在服务器响应中仅返回首部，不会返回主体数据。
• PUT：与GET方法相反，PUT回向服务器中写入文档。PUT的语义是让服务器用请求的主体部分来创建一个由所请求的URL命名的新文档。或者，如果那么URL所对应的资源已经存在的话，这个请求中的主体来替换原来的文档。
• POST：向服务器中发送数据。实际上，通常会用它来支持HTML表单。1
• DELETE：请服务器删除请求URL所指定的资源。
• TRACE：用于“环回”测试和诊断。客户端请求可能要穿过防火墙、代理、网关等中间节点才能达到最终的目的服务器，每个中间节点都可能会修改原始的HTTP请求，TRACE方法允许客户端看到它的请求最终变成了什么样子。下图是一个TRACE过程示例。尽管TRACE可以很方便的诊断，但它也有缺点。它假定中间节点对不同的类型的请求（比如不同的方法）会做相同的处理，实际上，不同类型的请求可能会做不同的处理，譬如，将POST请求直接发到应用服务器，而将GET请求发往缓存服务器。TRACE请求中不能带有实体的主体部分，响应报文中的主体部分是服务器收到的请求的精确副本。
  
• OPTIONS:请求服务器告知其支持的各种功能。可以询问服务器通常支持哪些方法，或者哪些特殊资源支持哪些方法。下面是一个OPTIONS方法示例：
  

下图是对HTTP协议中主要方法汇总：

上面的方法中，GET和HEAD方法是安全的方法，使用这些方法不会产生什么动作。POST等方法不是安全方法，POST方法会在服务器端生成新数据。假设是个请求扣款操作，多次执行POST操作有可能（如果服务端写的非常糟糕的话）会导致重复扣款。

HTTP状态码

HTTP中状态码的作用是告诉客户端发生了什么事，状态码位于响应报文的起始行中。HTTP中状态码使用三位数字来表示，根据最高位数据可以分为下面几类：

可用范围 已用范围 含义 100~199 100~101 信息提示 200~299 200~206 请求成功 300~399 300~305 重定向 400~499 400~415 客户端错误 500~599 300~305 服务端错误

下面来介绍一下使用开发中比较常用的状态码。

1、 100~199（信息性状态码）

HTTP/1.1向协议中引入的信息性状态码，由于对其复杂性和感知价值存在争议，因为使用受到限制。

状态码 原因短语 含义 100 Continue 说明服务端了请求的初始部分，请客户端继续。发送了这个状态码之后，服务器在收到请求之后必须进行响应 101 Switching Protocols 说明服务器正在根据客户端指定，将协议切换成Update首部所列的协议

2、 200~299（成功状态码）

客户端发起请求时，这些请求通常是成功的。这一段状态码表示成功的状态，分别对应不同类型的请求。

状态码 原因短语 含义 200 OK 请求没问题，实体的主体部分包含了所请求的资源 201 Created 用于创建服务器对象的请求。响应的实体主体部分中应该包含各种引用了已创建的资源和URL，Location首部包含的则是最具体的引用。 202 Accepted 请求已被接受，但服务器还未对其执行任何动作。不能保证服务器会完成这个请求，这是意味着接受请求时，它看起来是有效的。通常，该请求执行的是一个异步任务。 203 Non-Authoritative Information 实体首部包含的信息不是来源于源端服务器，而是来自资源的一份副本。如果中间节点上有一份资源副本，但无法或没有对它所发送的的资源相关的元信息进行验证，就会出现这种情况。 204 No Content 响应报文中包含若干首部和一个状态行，但没有实体的主体部分。主要用于在浏览器不转为显示新文档的情况下，对其进行更新 205 Reset Content 负责告知浏览器清除当前页面中的所有HTML表单元素 206 Partial Content 成功执行了一个部分或Range请求。 必须包含Content Range、Date以及Etag或者Content-Location首部

3、 300~399（重定向状态码）

重定向响应码要么告知客户端使用替代位置来访问他们所感兴趣的资源，那么提供一个替代的响应而不是替代的内容。如果原来的资源已经被移走，可发送一个重定向状态码和一个可选的Location首部来告知客户端资源已经被移走了。

状态码 原因短语 含义 300 Multiple Chioces 客户端一个请求实际上指向多个资源的URL时会返回这个状态码，比如服务器上有某个HTML文档的中文和英文版本。返回这个状态时会带有一个选项列表，这样用户就可以选择他希望的那一项了。 301 Moved Permanently 请求的URL链接已被永久移除， Location中首部中包含资源现在处的URL。 302 Found 与301状态码类似，但是，它表示URL临时移除。客户端应该使用Location首部给出的URL来临时定位资源。将来的请求仍然使用老的URL。 303 See Other 告知客户端应该使用另外一个URL来获取资源。新的URL位于响应报文的Location首部。其主要目的是允许POST请求的响应将客户端定位到某个资源上去。 304 Not Modified 客户端可以通过所包含的首部（如If-Modifid-Since），使得请求是有条件的。如果客户端发起一个GET请求，而该资源未被修改，就可以返回这个状态码。响应报文不应该包含主体内容。 305 Use Proxy 用来说明必须通过指定的代理来访问资源，代理的位置有Location首部提供。很重要的一点，客户端是相对某个特定的资源来解析这条响应，不能假定所有的请求都通过这个代理。 306 （还未使用） 还未被使用 307 Temporary Redirect 与302的作用相同，用于HTTP/1.1。

从上表中可以看出，302、303、307的状态码功能非常相似，它们有些细微的差别，大部分差别来源于HTTP/1.0和HTTP/1.1应用程序对这些状态码的处理不同。

当HTTP/1.0客户端发起POST请求，并在收到302响应时，它会接受Location首部的重定向URL，并向那么URL发起一个GET请求（而不是向原始请求的那样发起POST请求）。问题在于，在HTTP/1.1中使用303状态码实现了与HTTP/1.0中的302状态码的相同功能。为了避开这个问题，HTTP/1.1规范指出，对于HTTP/1.1客户端，用307状态码取代302状态码来进行临时重定向。这个服务器就把302状态码保留起来，为HTTP/1.0可以使用了。

这样一来，服务器要选择适当的重定向状态码放入重定向响应中，就需要查看客户端的HTTP版本了。

4、 400~499（客户端错误状态码）
有时客户端会发送一些服务器无法处理的请求，比如格式错误的请求报文，或者最常见的是，请求一个不存在的URL。很多客户端错误都是有浏览器来处理的，甚至不会打扰到用户。只有少量的错误，比如404会来到用户的面前。

状态码 原因短语 含义 400 Bad Request 用于告知客户端它发送了一个错误的请求。 401 Unauthorized 与适当的首部一同返回，在这些首部中请求客户端在获取资源前，需进行认证。 402 Payment Required 保留，还未使用？ 403 Forbidden 说明请求被服务端拒绝了。 可以在主体内容中说明拒绝原因，但这个状态码通常用于不想说明原因的场景。 404 Not Found 用于说明服务器无法找到所请求的URL。 405 Method Not Allowed 发起的请求的方法不被服务端支持时，使用此状态码。响应中应该使用Allow首部来告知所请求的资源可使用的方法。 406 Not Acceptable 客户端可以指定参数来说明它们愿意接受什么类型的实体，如果服务器没有与客户端可接受URL相匹配时，使用这个状态码。 407 Proxy Authetication Required 与401的作用相似，但用于要求对资源进行认证的代理服务器。 408 Request Timeout 如果客户端的请求所花的时间太长，服务器可以返回次状态码，并关闭连接。 409 Conflict 用于说明请求可能在资源上引发的一些冲突，服务器担心可能发生冲突时，可以发送此状态码。 410 Gone 与404类似，只是服务器曾经拥有过此资源。主要用于Web站点的维护，这样服务器的管理者就可以在资源被移除的情况下通知客户端了。 411 Length Required 服务器要求在请求报文中包含Content-Length首部时使用。 412 Precodition Failed 客户端发起条件请求，且其中的一个条件失败了的使用使用。客户端包含了Expact首部时发起的请求就是条件请求。 413 Request Entity Too Large 客户端所发送的实体比服务器能够或者处理的要大。 414 Request URI Too Long 客户端所请求的的URL长度比服务器能够或者处理的要长。 415 Unsupport Media Type 服务器无法理解或支持客户端发送的内容类型。 416 Request Range Not Satisfiable 客户端请求的资源的范围无法被满足。 417 Expaction Failed 请求的Expact首部包含一个期望，如果期望不能被满足时，使用这个状态码。

5、 500~599（服务器出错状态码）
如果客户端发送了一个请求，服务端自身发生了错误，就会返回这么段的状态码。

状态码 原因短语 含义 500 Internal Server Error 服务端遇到一个妨碍它为请求提供服务的错误时，使用此状态码。 501 Not Implemented 请求超过了服务端的能力范围时，返回这个响应码。 502 Bad Gateway 代理或者网关使用的服务器收到链路上的下一个节点的伪响应（比如，无法连接到其父网关）时，使用此状态码。 503 Service Unavailable 用来说明服务器现在无法为请求提供服务，但是将来可以。如果服务器知道服务何时可用，可在响应中包含一个Retry-After首部。 504 Gateway Timeout 与状态码408类似，只是响应来自网关或代理，它们在等待另外的服务器对其请求响应时超时。 505 HTTP Version Not Supported 服务器收到的请求使用了它无法或者不愿意支持的协议版本时，返回此状态码。

下面自己试着总结一下这些HTTP状态码：

1. 4XX错误种类最多。客户端是软件开发者能掌控的最弱的环节，也是可能出错最多的地方；
2. 有些状态码的语义比较模糊（比如400、500），通用性很强，不利于定位错误。所以，在实际开发中应该尽量少用这种语义模糊的状态码。
3. 有些状态码语义有些重叠和相似。比如405和501这两个状态码，虽然405的错误更加明确，但都是表示服务端无法处理这个请求。那么到底是客户端使用了未实现或未允许的方法呢？还是服务器无法处理这个请求呢？语义的重叠带来了开发中的选择困难。

HTTP首部详解

首部和方法配合，共同绝对了客户端和服务端能够做什么。在请求和响应报文中都可以用首部来提供信息，按照首部所处的端点和位置可以将首部分成5类：

1. 通用首部：客户端和服务端都可以使用的首部。
2. 请求首部：请求报文中特有的首部。
3. 响应首部：响应报文中特有的首部。
4. 实体首部：对应于实体主体部分的首部。
5. 扩展首部：应用开发者自己创建的首部。

通用首部

通用首部提供了一些最基本的信息，下表列出了一些常用的通用首部。

首部 含义 Connection 客户端和服务端指定与请求/响应连接相关的选项。 Date 提供日期和时间标志，说明报文是什么时间创建的。 MINE-Vesion 发送端使用的MINE的版本。 Transfer-Encoding 告知接收端报文采用何种编码方式。 Update 告知发送端可能想要“升级”使用的新版本或协议。 Via 显示报文经过的中间节点（代理、网关）。 Cache-Control 指示缓存方式。 Prama 另外一种随报文传送的指示的方式，但并不专用于缓存。

请求首部

请求首部是只在请求报文中有意义的首部。用于说明是谁或什么在发送请求、请求源于何处。可以根据首部的功能来对请求首部进行分类。

1、 信息性请求首部

首部 含义 Client-IP 提供运行客户端的主机IP。 From 提供了客户端用户的Email地址。 Host 提供了接受请求的服务器的主机名和端口。与起始行中的URL路径结合起来，组成了一个完整的绝对URL地址。 Referer 提供了包含了当前URI的文档的URL。 比如，点击URL为www.xx.com的页面中的任意链接，请求中会带上Referer: www.xx.com的首部。 User-Agent 将发起请求的应用程序告知服务端。如果想模拟浏览器请求来做个爬虫，通常都会加上这个首部。

2、 Accept首部
Accept首部为客户端提供了一种将其喜好和能力告知服务器的方式。可以告知服务端它们想要什么，可以使用什么，以及不想要什么。服务端可以根据这些首部，来做发送的内容作出更加明智的决定。

首部 含义 Accept 告知服务端客户发送哪些媒体类型。 Accept-Charset 告诉服务端能够发送哪些字符集。 Accept-Encoding 告知服务端可以使用哪些编码方式。 Accept-Language 告知服务端能够发送哪些语言。

3、 条件请求首部
通过条件请求首部，客户端可以为请求加上限制，要求服务器在对请求响应之前，确保某个条件为真。

首部 含义 Expect 允许客户端列出请求所要求的服务端行为。 If-Match 如果服务端的实体标记与当前的实体标记相匹配时，就获取这份文档。 If-None-Match 如果服务端的实体标记与当前的实体标记相匹配时，就获取这份文档。 If-Modified-Since 如果请求的文档在指定的日期后修改过，就获取这份文档。 If-Unmodified-Since 如果请求的文档在指定的日期后没有修改过，就获取这份文档。 If-Range 如果服务端支持范围请求，就进行响应。 Range 指定一个请求范围。

4、 安全请求首部
HTTP本身就支持一种简单的机制，可以对请求进行质询/响应认证。客户端在请求资源时，需要带上安全请求首部才能获取特定的资源。

首部 含义 Authorization 包含客户端对自身进行认证的数据。 Cookie 客户端向服务端传送的一个令牌。

5、 代理请求首部

首部 含义 Max-Forward 在通往源端服务器的路径上，将请求转发给其他代理或网关的最大次数（与Trace方法一同使用）。 Proxy-Authorization 与Authorization首部含义相同，只不过用于代理认证。 Proxy-Connection 与Connection首部含义相同，用于与代理建立连接时使用。

响应首部

响应首部为客户端提供一些额外信息，比如谁在发送响应，响应者的功能，甚至与响应相关的一些特殊指令。这些首部有利于客户端处理响应，并在将来发起跟高的请求。

1、 信息性响应首部

首部 含义 Age 从最初创建开始，响应持续时间。 Retry-After 如果当前资源不可用，在此日期或时间重试。 Server 服务器应用程序软件的名称和版本。 Title 对于HTML文档来说，就是HTML文档的源端给出的标题。 Warning 比起始行中的原因短语更加详细的警告信息。

2、 协商响应首部

首部 含义 Accept-Ranges 对此资源来说，服务器可接受的范围类型。 Vary 服务器查看的其他首部的列表，可能会使响应发生变化。也就是说，这是个首部列表，服务器会根据这些首部的内容挑选出合适的资源版本发给客户端。

3、 安全响应首部

首部 含义 Proxy-Authenicate 代理可客户端的质询列表。 Set-Cookie 在客户端设置一个令牌，以便对客户端进行标识。 WWW-Authenicate 来自服务器对客户端的质询列表。 Title 对于HTML文档来说，就是HTML文档的源端给出的标题。 Warning 比起始行中的原因短语更加详细的警告信息。

实体首部

有很对首部用来描述HTTP的负荷，由于请求和响应中都可能包含实体部分，所以在这两张报文中都可能出现这类首部。

实体首部提供了实体及其内容的的大量信息，从有关对象类型的信息，到能够对资源使用的各种有效的请求方法。总之，实体首部可以告知报文的接受者它在对什么进行处理。

1、 信息性实体首部

首部 含义 Allow 列出可以对实体执行的请求方法。 Location 告知客户端实体实际位于何处，用于将接收端定向到资源的位置上去。

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

首部 含义 Conntent-Base 解析主体中相对URL时所使用的基础URL。 Conntent-Encoding 对主体执行的编码方式。 Conntent-Language 理解主体时最适合使用的自然语言。 Conntent-Length 主体的长度或尺寸。 Conntent-Location 资源主体实际所处的位置。 Conntent-MD5 主体的MD5校验和。 Conntent-Range 在整个资源中，此实体表示的字节范围。 Conntent-Type 这个主体的对象类型。

3、 实体缓存首部
缓存首部说明了如何或什么时候进行缓存。

首部 含义 Etag 与此实体相关的实体标记。 Expires 实体不再有效，要从原始的源端再次获取此实体的日期和时间。 Last-Modified 实体最后一次被修改的日期和时间。

读后反省

读了本节内容，再联系到自己在实际开发过程中对HTTP协议的运用，发现之前用的不正确、不合理。下面是自己总结的用的不正确的地方：

1. 除了post、get方法外的方法，基本上没有用过其他HTTP方法。HTTP是应用层协议，与自己开发的应用程序属于同一个网络层次。只不过它给我们解决了网络应用程序中的通用性问题，让应用软件开发者可以将重心放在应用内容本身。既然HTTP协议本身已经定义了这么多的执行动作的方法，就不应该弃之不用。必然要删除某个资源，完全可以使用delete方法来标志删除动作。 最近在研究rest这种Web应用设计思想，它可以使得应用程序充分运用HTTP协议。
2. URL误用。URL是资源的唯一标识符，指示资源的位置和获取方式。从语言词性层面来说，这样的描述性短语应该是一个名词性短语，所以诸如www.xx.com/getUsers、/deleteUser?id=11之类URL都属于误用。
3. 很少使用除了200、404、500以外的状态码来描述响应状态。既然HTTP协议与应用数据属于同一个网络层次，如果HTTP中定义的状态码足以描述当前的状态，就应该优先使用它们，而不是使用自定义的状态。

在这篇文章以前，自己已经阅读过HTTP状态码、首部等内容很多次了，但就是记不住。读一遍记不住，读十遍也就是那样。但是，自己这么完整的复写过一遍之后，对整个HTTP协议细节有了更深的认识，而且也能够勉强记住了。好记性不如烂笔头，确实是这么一个道理。虽然把人家书上的内容是照搬了过来，相当了又重复造了一遍轮子，但是对笔者来说却相当收益。技术提高没有什么捷径可走，要的就是更多地去实践，造轮子不失为一种技术提高的有效办法。

总结

本文是有关HTTP学习的第二篇的文章，主要介绍了HTTP协议中的报文，包括报文组成、语法结构、方法、状态码和详细的首部介绍。内容以《HTTP权威指南》为主，同时加入了自己的理解。在文章的末尾谈了谈阅读和写完本章内容之后的感想，以及对自己今后开发上可能的帮助。同时也反思一下自己本身的不足，要好好加油才是！本文历时了2个多星期才写完，不是因为时间不够，实在是懒癌症太厉害了。而且，工作上也不是很如意，有时候回家后啥都不想干。最后还是写完了，坚持就是胜利。Keep learning！

---

1. 注意与PUT方法的区别，POST向服务器发送数据，PUT用于向服务器中的资源（比如文件）中存储数据。 ↩