图解HTTP----HTTP首部--概述及通用首部字段

一、HTTP报文首部

（1）HTTP协议的请求和响应报文中必定包含HTTP首部。

（2）首部内容为客户端和服务器分别处理请求和响应提供所需要的信息。

（3）报文首部由几个字段构成

（4）首部字段同时存在于请求和响应报文内，并涵盖HTTP报文相关的内容信息。

• HTTP请求报文

（1）在请求中，HTTP报文由方法、URI、HTTP版本、HTTP首部字段等部分构成。

• HTTP响应报文

（1）在响应中，HTTP报文由HTTP版本、状态码（数字和原因短语）、HTTP首部字段3部分构成。

二、HTTP首部字段

• HTTP首部字段传递重要信息

（1）HTTP首部字段是构成HTTP报文的要素之一。

（2）在客户端与服务器之间以HTTP协议进行通信的过程中，无论是请求还是响应都会使用首部字段，它能起到传递额外重要信息的作用。

（3）使用首部字段是为了给浏览器和服务器提供报文主体大小、所使用的语言、认证信息等内容。

• HTTP首部字段结构

（1）HTTP首部字段是由首部字段名和字段值构成，中间用冒号“：”分隔。

首部字段名：字段值

（2）字段值对应单个HTTP首部字段可以有多个值

Keep-Alive: timeout=15, max=100

（3）若HTTP首部字段重复了会如何

这种情况在规范内尚未明确，根据浏览器内部处理逻辑的不同，结果可能并不一致。有些浏览器会优先处理第一次出现的首部字段，而有些则会优先处理最后出现的首部字段。

• 4种HTTP首部字段类型

HTTP首部字段根据实际用途被分为以下4种类型

通用首部字段（General Header Fields）

请求报文和响应报文两方都会使用的首部

请求首部字段（Request Header Fields）

从客户端向服务器端发送请求报文时使用的首部。补充了请求的附加内容、客户端信息、响应内容相关优先级等信息

响应首部字段（Response Header Fields）

从服务器端向客户端返回响应报文时使用的首部。补充了响应的附加内容，也会要求客户端附加额外的内容信息。

实体首部字段（Entity Header Fields）

针对请求报文和响应报文的实体部分使用的首部。补充了资源内容更新时间等与实体有关的信息。

• HTTP/1.1首部字段一览

• 非HTTP/1.1首部字段

在 HTTP 协议通信交互中使用到的首部字段，不限于 RFC2616 中定义的 47 种首部字段。还有 Cookie、Set-Cookie 和 Content-Disposition等在其他 RFC 中定义的首部字段，它们的使用频率也很高。这些非正式的首部字段统一归纳在 RFC4229 HTTP Header FieldRegistrations 中。

• End-to-end 首部和Hop-by-hop首部

HTTP首部字段将定义成缓存代理和非缓存代理的行为，分成2种类型。

（1）端到端首部（End-to-end Header）

分在此类别中的首部会转发给请求/响应对应的最终接收目标，且必须保存在由缓存生成的响应中，另外规定它必须被转发。

（2）逐跳首部（Hop-by-hop Header）

分在此类别中的首部只对单次转发有效，会因通过缓存或代理而不再转发。在HTTP/1.1和之后的版本中，如果要使用hop-by-hop

首部，需要提供Connection首部字段。

（3）下面列举了 HTTP/1.1 中的逐跳首部字段。除这 8 个首部字段之外，其他所有字段都属于端到端首部。

三、HTTP/1.1通用首部字段

通用首部字段是指，请求报文和响应报文双方都会使用的首部

• Cache-Control（控制缓存行为）

（1）通过制定首部字段Cache-Control的指令，就能操作缓存的工作机制。

（2）指令的参数是可选的，多个指令之间通过“，”分隔。

（3）首部字段Cache-Control的指令可用于请求及响应时。

Cache-Control: private, max-age=0, no-cache

（4）Cache-Control指令一览

（5）表示是否能缓存的指令

• public指令

Cache-Control: public

1）当指定使用public指令时，则明确表明其他用户也可利用缓存。

• private指令

Cache-Control: private

1）当指定private指令后，响应只以特定的用户作为对象，这与public指令的行为相反。

2）缓存服务器会对该特定用户提供资源缓存的服务，对于其他用户发送过来的请求，代理服务器则不会返回缓存。

• no-cache指令

Cache-Control: no-cache

1）使用no-cache指令的目的是为了防止从缓存中返回过期的资源。

2）客户端发送的请求中如果包含no-cache指令，则表示客户端将不会接受缓存过的响应。于是，“中间”缓存服务器必须把客户端请求转发给源服务器。

3）如果服务器返回的响应中包含no-cache 指令，那么缓存服务器不能对资源进行缓存。源服务器以后也将不再对缓存服务器请求中提出的资源有效性进行确认，且禁止其对响应资源进行缓存操作。

4）由服务器返回的响应中，若报文首部字段Cache-Control中对no-cache字段名具体指定参数值，那么客户端在接收到这个被指定参数值的首部字段对应的响应报文后，就不能使用缓存。换言之，无参数值的首部字段可以使用缓存。只能在响应指令中指定该参数值。

Cache-Control: no-cache=Location

（6）控制可执行缓存的对象的指令

• no-store

Cache-Control: no-store

1）当使用no-store指令时，暗示请求（和对应的响应）或响应中包含机密信息。因此，该指令规定缓存不能在本地存储请求或响应的任一部分。

2）从字面意思上很容易把 no-cache 误解成为不缓存，但事实上 no-cache 代表不缓存过期的资源，缓存会向源服务器进行有效期确认后处理资源，也许称为 do-notserve-from-cache-without-revalidation 更合适。no-store 才是真正地不进行缓存。

（7）指定缓存期限和认证的指令

• s-maxage指令

Cache-Control: s-maxage=604800（单位 ：秒）

1）s-maxage指令的功能和max-age指令相同，它们的不同点是s-maxage指令只适用于供多位用户适用的公共缓存服务器。也就是说，对于向同一用户重复返回响应的服务器来说，这个指令没有任何作用。

2）当使用s-maxage指令后，则直接忽略对Expires首部字段及max-age指令的处理。

• max-age指令

Cache-Control: max-age=604800（单位：秒）

1）当客户端发送的请求中包含max-age指令时，如果判定缓存资源的缓存时间数值比指定时间的数值更小，那么客户端就接收缓存的资源。

2）当指定max-age值为0，那么缓存服务器通常需要将请求转发给源服务器。

3）当服务器返回的响应中包含max-age指令时，缓存服务器将不对资源的有效性再作确认，而max-age数值代表资源保存为缓存的最长时间。

4）应用 HTTP/1.1 版本的缓存服务器遇到同时存在 Expires 首部字段的情况时，会优先处理 max-age 指令，而忽略掉 Expires 首部字段。而HTTP/1.0 版本的缓存服务器的情况却相反，max-age 指令会被忽略掉。

• min-fresh指令

Cache-Control: min-fresh=60（单位：秒

1）min-fresh指令要求缓存服务器返回至少还未过指定时间的缓存资源。

2）比如，当指定min-fresh为60秒后，在这60秒以内如果有超过有效期限的资源都无法作为响应返回了。

• max-stale

Cache-Control: max-stale=3600（单位：秒）

1）使用max-stale可指示缓存资源，即使过期也照常接收。

2）如果指令未指定参数值，那么无论经过多久，客户端都会接收响应。

3）如果指令指定了具体数值，那么即使过期，只要仍处于max-stale指定的时间内，仍旧会被客户端接收。

• only-if-cached指令

Cache-Control: only-if-cached

1）使用only-if-cached指令表示客户端仅在缓存服务器本地缓存目标资源的情况下才会要求其返回。换言之，该指令要求缓存服务器不重新加载响应，也不会再次确认资源有效性。

2）若发生请求缓存服务器的本地缓存无响应，则返回状态码504 Gateway Timeout。

• must-revalidate指令

Cache-Control: must-revalidate

1）使用must-revalidate指令，代理会向源服务器再次验证即将返回的响应缓存目前是否仍然有效。

2）若代理无法连通源服务器再次获取有效资源的话，缓存必须给客户端一条504 Gateway Timeout 状态码。

3）使用 must-revalidate指令会忽略请求的max-stale指令（即使已经在首部使用max-stale，也不会再有效果）

• proxy-revalidate指令

Cache-Control: proxy-revalidate

1）proxy-revalidate指令要求所有的缓存服务器在接收到客户端带有该指令的请求返回响应之前，必须再次验证缓存的有效性。

• no-transform指令

Cache-Control: no-transform

1）使用no-transform指令规定无论是在请求还是响应中，缓存都不能改变实体主体的媒体类型。

2）这样做可以防止缓存或代理压缩图片等类似操作。

（8）Cache-Control 扩展

cache-extension token

Cache-Control: private, community="UCI"

1）通过 cache-extension 标记（token），可以扩展 Cache-Control 首部字段内的指令。

2）如上例，Cache-Control 首部字段本身没有 community 这个指令。借助extension tokens 实现了该指令的添加。

3）如果缓存服务器不能理解community 这个新指令，就会直接忽略。因此，extension tokens 仅对能理解它的缓存服务器来说是有意义的。

• Connection（逐跳首部、连接的管理）

• 控制不再转发给代理的首部字段
• 管理持久连接

（1）控制代理不再转发的首部字段

Connection: 不再转发的首部字段名

1）在客户端发送请求和服务器返回响应内，使用Connection首部字段，可控制不再转发给代理的首部字段（即Hop-by-hob首部）

（2）管理持久连接

Connection: close

Connection: Keep-Alive

1）HTTP/1.1 版本的默认连接都是持久连接。为此，客户端会在持久连接上连续发送请求。

2）当服务器端想明确断开连接时，则指定Connection首部字段的值为Close。

3）HTTP/1.1 之前的 HTTP 版本的默认连接都是非持久连接。为此，如果想在旧版本的 HTTP 协议上维持持续连接，则需要指定Connection 首部字段的值为 Keep-Alive。

如上图①所示，客户端发送请求给服务器时，服务器端会像上图②那样加上首部字段 Keep-Alive 及首部字段 Connection 后返回
响应。

• Date（创建报文的日期时间）

首部字段Date表明创建HTTP报文的日期和时间。

1）HTTP/1.1 协议使用在 RFC1123 中规定的日期时间的格式

Date: Tue, 03 Jul 2012 04:40:59 GMT

2）之前的 HTTP 协议版本中使用在 RFC850 中定义的格式

Date: Tue, 03-Jul-12 04:40:59 GMT

3）除此之外，还有一种格式。它与 C 标准库内的 asctime() 函数的输出格式一致。

Date: Tue Jul 03 04:40:59 2012

• Pragama（报文指令）

Pragma 是 HTTP/1.1 之前版本的历史遗留字段，仅作为与 HTTP/1.0的向后兼容而定义。

1）规范定义的形式唯一

Pragma: no-cache

2）该首部字段属于通用首部字段，但只用在客户端发送的请求中。客户端会要求所有的中间服务器不返回缓存的资源。

3）所有的中间服务器如果都能以 HTTP/1.1 为基准，那直接采用 CacheControl: no-cache 指定缓存的处理方式是最为理想的。但要整体掌握全部中间服务器使用的 HTTP 协议版本却是不现实的。因此，发送的请求会同时含有下面两个首部字段。

Cache-Control: no-cache
Pragma: no-cache

• Trailer（报文末端首部一览）

1）首部字段Trailer会事先说明在报文主体后记录了哪些首部字段。

2）该首部端可应用在HTTP/1.1版本分块传输编码时。

HTTP/1.1 200 OK
Date: Tue, 03 Jul 2012 04:40:56 GMT
Content-Type: text/html
...
Transfer-Encoding: chunked
Trailer: Expires
...(报文主体)...
0
Expires: Tue, 28 Sep 2004 23:59:59 GMT

以上用例中，指定首部字段 Trailer 的值为 Expires，在报文主体之后（分块长度 0 之后）出现了首部字段 Expires。

• Transfer-Encoding（指定报文主体的传输编码方式）

1）首部字段Transfer-Encoding规定了传输报文主体时采用的编码方式。

2）HTTP/1.1的传输编码方式仅对分块传输编码有效。

以上用例中，正如在首部字段 Transfer-Encoding 中指定的那样，有效使用分块传输编码，且分别被分成 3312 字节和 914 字节大小的分块数据。

• Upgrade（升级为其他协议）

1）首部字段Upgrade用于检测HTTP协议及其他协议是否可使用更高级的版本进行通信，其参数值可以用来指定一个完全不同的通信协议。

2）Upgrade首部字段产生作用的Upgrade对象仅限于客户端和l邻接服务器之间。因此，使用首部字段Upgrade时，还需要额外指定Connection：Upgrade。

3）对于附有首部字段Upgrade的请求，服务器可用101 Switching Protocols 状态码作为响应返回。

• Via（代理服务器的相关信息，用于追踪传输路径）

行头的 1.0 是指接收请求的服务器上应用的 HTTP 协议版本。

1）使用首部字段Via是为了追踪客户端与服务器之间的请求和响应报文的传输路径。

2）报文经过代理或网关时，会先在首部字段Via中附加该服务器的信息，然后再进行转发。这个做法和traceroute及电子邮件的Received首部的工作机制很类似。

3）首部字段Via不仅用于追踪报文的转发，还可避免请求回环的发生。所以必须在经过代理时附加该首部字段内容。

4）在Via首部附加服务器信息，也可增加1个新的Via首部写入服务器信息。

5）Via首部是为了追踪传输路径，所以经常和TRACE方法一起使用。

比如，代理服务器接收到由 TRACE 方法发送过来的请求（其中Max-Forwards: 0）时，代理服务器就不能再转发该请求了。这种情况下，代理服务器会将自身的信息附加到 Via 首部后，返回该请求的响应。

• Warning（错误通知）

1）HTTP/1.1的Warning首部是从HTTP/1.0的响应首部（Retry-After）演变过来的。

2）该首部通常会告知用户一些与缓存相关的问题的警告。

Warning: 113 gw.hackr.jp:8080 "Heuristic expiration" Tue, 03 Jul =》2012 05::09:44 GMT

3）首部格式如下。最后的日期时间部分可省略。

Warning: [警告码][警告的主机:端口号]“[警告内容]”([日期时间])

4）HTTP/1.1中定义了7种警告。警告码对应的警告内容仅推荐参考。另外，警告码具有扩展性，今后有可能追加新的警告码。