《图解Http》阅读笔记——6.HTTP 首部

《图解Http》阅读笔记——6.HTTP 首部

---

6.1 HTTP 报文首部

图：HTTP 报文的结构

HTTP 协议的请求和响应报文中一定包含 HTTP 首部。首部内容为客 户端和服务器分别处理请求和响应提供所须要的信息。对于客户端用 户来讲，这些信息中的大部份内容都无须亲自查看。

报文首部由几个字段构成。

HTTP 请求报文

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

图：请求报文

下面的示例是访问 http://hackr.jp 时，请求报文的首部信息。

GET / HTTP/1.1
Host: hackr.jp
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*; q=0.8
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
If-Modified-Since: Fri, 31 Aug 2007 02:02:20 GMT
If-None-Match: "45bae1-16a-46d776ac"
Cache-Control: max-age=0

HTTP 响应报文

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

图：响应报文

如下示例是以前请求访问 http://hackr.jp/ 时，返回的响应报文的首部 信息。

HTTP/1.1 304 Not Modified
Date: Thu, 07 Jun 2012 07:21:36 GMT
Server: Apache
Connection: close
Etag: "45bae1-16a-46d776ac"

在报文众多的字段当中，HTTP 首部字段包含的信息最为丰富。首部 字段同时存在于请求和响应报文内，并涵盖 HTTP 报文相关的内容信 息。

因 HTTP 版本或扩展规范的变化，首部字段可支持的字段内容略有不 同。本书主要涉及 HTTP/1.1 及经常使用的首部字段

6.2 HTTP 首部字段

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

HTTP 首部字段是构成 HTTP 报文的要素之一。在客户端与服务器之 间以 HTTP 协议进行通讯的过程当中，不管是请求仍是响应都会使用首 部字段，它能起到传递额外重要信息的做用。

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

6.2.2 HTTP 首部字段结构

HTTP 首部字段是由首部字段名和字段值构成的，中间用冒号“:” 分 隔。

首部字段名: 字段值

例如，在 HTTP 首部中以 Content-Type 这个字段来表示报文主体的 对 象类型。

Content-Type: text/html

另外，字段值对应单个 HTTP 首部字段能够有多个值，以下所示。

Keep-Alive: timeout=15, max=100

若 HTTP 首部字段重复了会如何 当 HTTP 报文首部中出现了两个或两个以上具备相同首部字段名时 会怎么样？这种状况在规范内还没有明确，根据浏览器内部处理逻辑 的不一样，结果可能并不一致。有些浏览器会优先处理第一次出现的 首部字段，而有些则会优先处理最后出现的首部字段。

6.2.3 4 种 HTTP 首部字段类型

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

通用首部字段（General Header Fields）

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

请求首部字段（Request Header Fields）

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

响应首部字段（Response Header Fields）

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

实体首部字段（Entity Header Fields）

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

6.2.4 HTTP/1.1 首部字段一览

表 6-1：通用首部字段

首部字段名	说明
Cache-Control	控制缓存的行为
Connection	逐跳首部、链接的管理
Date	建立报文的日期时间
Pragma	报文指令
Trailer	报文末端的首部一览
Transfer-Encoding	指定报文主体的传输编码方式
Upgrade	升级为其余协议
Via	代理服务器的相关信息
Warning	错误通知

表 6-2：请求首部字段

首部字段名	说明
Accept	用户代理可处理的媒体类型
Accept-Charset	优先的字符集
Accept-Encoding	优先的内容编码
Accept-Language	优先的语言（天然语言）
Authorization	Web认证信息
Expect	期待服务器的特定行为
From	用户的电子邮箱地址
Host	请求资源所在服务器
If-Match	比较实体标记（ETag）
If-Modified-Since	比较资源的更新时间
If-None-Match	比较实体标记（与 If-Match 相反）
If-Range	资源未更新时发送实体 Byte 的范围请求
If-Unmodified-Since	比较资源的更新时间（与If-Modified-Since相反）
Max-Forwards	最大传输逐跳数
Proxy-Authorization	代理服务器要求客户端的认证信息
Range	实体的字节范围请求
Referer	对请求中 URI 的原始获取方
TE	传输编码的优先级
User-Agent	HTTP 客户端程序的信息

表 6-3：响应首部字段

首部字段名	说明
Accept-Ranges	是否接受字节范围请求
Age	推算资源建立通过时间
ETag	资源的匹配信息
Location	令客户端重定向至指定URI
Proxy-Authenticate	代理服务器对客户端的认证信息
Retry-After	对再次发起请求的时机要求
Server	HTTP服务器的安装信息
Vary	代理服务器缓存的管理信息
WWW-Authenticate	服务器对客户端的认证信息

表 6-4：实体首部字段

首部字段名		说明
Allow	资源可支持的HTTP方法
Content-Encoding	实体主体适用的编码方式
Content-Language	实体主体的天然语言
Content-Length	实体主体的大小（单位：字节）
Content-Location	替代对应资源的URI
Content-MD5	实体主体的报文摘要
Content-Range	实体主体的位置范围
Content-Type	实体主体的媒体类型
Expires	实体主体过时的日期时间
Last-Modified	资源的最后修改日期时间

6.2.5 非 HTTP/1.1 首部字段

在 HTTP 协议通讯交互中使用到的首部字段，不限于 RFC2616 中定 义的 47 种首部字段。还有 Cookie、Set-Cookie 和 Content-Disposition 等在其余 RFC 中定义的首部字段，它们的使用频率也很高。

这些非正式的首部字段统一概括在 RFC4229 HTTP Header Field Registrations 中。

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

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

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

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

分在此类别中的首部只对单次转发有效，会因经过缓存或代理而再也不 转发。HTTP/1.1 和以后版本中，若是要使用 hop-by-hop 首部，需提 供 Connection 首部字段。

下面列举了 HTTP/1.1 中的逐跳首部字段。除这 8 个首部字段以外， 其余全部字段都属于端到端首部。

• Connection
• Keep-Alive
• Proxy-Authenticate
• Proxy-Authorization
• Trailer
• TE
• Transfer-Encoding
• Upgrade

6.3 HTTP/1.1 通用首部字段

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

6.3.1 Cache-Control

经过指定首部字段 Cache-Control 的指令，就能操做缓存的工做机 制。

图：首部字段 Cache-Control 可以控制缓存的行为

指令的参数是可选的，多个指令之间经过“,”分隔。首部字段 CacheControl 的指令可用于请求及响应时。

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

• Cache-Control 指令一览

可用的指令按请求和响应分类以下所示。

表 6-5：缓存请求指令

指令	参数	说明
no-cache	无	强制向源服务器再次验证
no-store	无	不缓存请求或响应的任何内容
max-age = [ 秒]	必需	响应的最大Age值
max-stale( = [ 秒])	可省略	接收已过时的响应
min-fresh = [ 秒]	必需	指望在指定时间内的响应仍有效
no-transform	无	代理不可更改媒体类型
only-if-cached	无	从缓存获取资源
cache-extension	-	新指令标记（token）

表 6-6：缓存响应指令

指令	参数	说明
public	无	可向任意方提供响应的缓存
private	可省略	仅向特定用户返回响应
no-cache	可省略	缓存前必须先确认其有效性
no-store	无	不缓存请求或响应的任何内容
no-transform	无	代理不可更改媒体类型
must-revalidate	无	可缓存但必须再向源服务器进行确认
proxy-revalidate	无	要求中间缓存服务器对缓存的响应有效性再进行确认
max-age = [ 秒]	必需	响应的最大Age值
s-maxage = [ 秒]	必需	公共缓存服务器响应的最大Age值
cache-extension	-	新指令标记（token）

表示是否能缓存的指令

public 指令

Cache-Control: public

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

private 指令

Cache-Control: private

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

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

no-cache 指令

Cache-Control: no-cache

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

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

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

Cache-Control: no-cache=Location

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

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

no-store 指令

Cache-Control: no-store

当使用 no-store 指令[1]时，暗示请求（和对应的响应）或响应中包含 机密信息。

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

所以，该指令规定缓存不能在本地存储请求或响应的任一部分

指定缓存期限和认证的指令

s-maxage 指令

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

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

2 这里通常指代理。 ——译者注

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

max-age 指令

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

当客户端发送的请求中包含 max-age 指令时，若是断定缓存资源的缓 存时间数值比指定时间的数值更小，那么客户端就接收缓存的资源。 另外，当指定 max-age 值为 0，那么缓存服务器一般须要将请求转发 给源服务器。

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

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

min-fresh 指令

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

max-stale 指令

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

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

若是指令未指定参数值，那么不管通过多久，客户端都会接收响应； 若是指令中指定了具体数值，那么即便过时，只要仍处于 max-stale 指定的时间内，仍旧会被客户端接收。

only-if-cached 指令

Cache-Control: only-if-cached

使用 only-if-cached 指令表示客户端仅在缓存服务器本地缓存目标资 源的状况下才会要求其返回。换言之，该指令要求缓存服务器不从新 加载响应，也不会再次确认资源有效性。若发生请求缓存服务器的本 地缓存无响应，则返回状态码 504 Gateway Timeout。

must-revalidate 指令

Cache-Control: must-revalidate

使用 must-revalidate 指令，代理会向源服务器再次验证即将返回的响 应缓存目前是否仍然有效。 若代理没法连通源服务器再次获取有效资源的话，缓存必须给客户端 一条 504（Gateway Timeout）状态码。

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

proxy-revalidate 指令

Cache-Control: proxy-revalidate

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

no-transform 指令

Cache-Control: no-transform

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

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

Cache-Control 扩展

cache-extension token

Cache-Control: private, community="UCI"

经过 cache-extension 标记（token），能够扩展 Cache-Control 首部字 段内的指令。

如上例，Cache-Control 首部字段自己没有 community 这个指令。借助 extension tokens 实现了该指令的添加。若是缓存服务器不能理解 community 这个新指令，就会直接忽略。所以，extension tokens 仅对 能理解它的缓存服务器来讲是有意义的。

6.3.2 Connection

Connection 首部字段具有以下两个做用。

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

控制再也不转发给代理的首部字段

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

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

管理持久链接

onnection: close

HTTP/1.1 版本的默认链接都是持久链接。为此，客户端会在持 久链接上连续发送请求。当服务器端想明确断开链接时，则指定 Connection 首部字段的值为 Close

Connection: Keep-Alive

HTTP/1.1 以前的 HTTP 版本的默认链接都是非持久链接。为 此，若是想在旧版本的 HTTP 协议上维持持续链接，则须要指定 Connection 首部字段的值为 Keep-Alive。

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

6.3.3 Date

首部字段 Date 代表建立 HTTP 报文的日期和时间

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

以前的 HTTP 协议版本中使用在 RFC850 中定义的格式，以下所示。

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

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

Date: Tue Jul 03 04:40:59 2012

6.3.4 Pragma

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

规范定义的形式惟一，以下所示。

Pragma: no-cache

6.3.5 Trailer

首部字段 Trailer 会事先说明在报文主体后记录了哪些首部字段。该 首部字段可应用在 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。

6.3.6 Transfer-Encoding

首部字段 Transfer-Encoding 规定了传输报文主体时采用的编码方式。 HTTP/1.1 的传输编码方式仅对分块传输编码有效。

HTTP/1.1 200 OK
Date: Tue, 03 Jul 2012 04:40:56 GMT
Cache-Control: public, max-age=604800 Content-Type: text/javascript; charset=utf-8
Expires: Tue, 10 Jul 2012 04:40:56 GMT
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
Content-Encoding: gzip
Transfer-Encoding: chunked
Connection: keep-alive
cf0 ←16进制(10进制为3312)
...3312字节分块数据...
392 ←16进制(10进制为914)
...914字节分块数据...
0

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

6.3.7 Upgrade

首部字段 Upgrade 用于检测 HTTP 协议及其余协议是否可以使用更高的 版本进行通讯，其参数值能够用来指定一个彻底不一样的通讯协议。

上图用例中，首部字段 Upgrade 指定的值为 TLS/1.0。请注意此处两 个字段首部字段的对应关系，Connection 的值被指定为 Upgrade。 Upgrade 首部字段产生做用的 Upgrade 对象仅限于客户端和邻接服务 器之间。所以，使用首部字段 Upgrade 时，还须要额外指定 Connection:Upgrade。

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

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

6.3.8 Via

(略)

6.3.9 Warning

(略)

6.4 请求首部字段

请求首部字段是从客户端往服务器端发送请求报文中所使用的字段， 用于补充请求的附加信息、客户端信息、对响应内容相关的优先级等 内容。

6.4.1 Accept

Accept:text/html,application/xhtml+xml,application/xml;q=0.

Accept 首部字段可通知服务器，用户代理可以处理的媒体类型及媒体 类型的相对优先级。可以使用 type/subtype 这种形式，一次指定多种媒 体类型。

• 文本文件

  text/html, text/plain, text/css ... application/xhtml+xml, application/xml ...

• 图片文件

  image/jpeg, image/gif, image/png ...

• 视频文件

  video/mpeg, video/quicktime ...

• 应用程序使用的二进制文件 application/octet-stream, application/zip ...

好比，若是浏览器不支持 PNG 图片的显示，那 Accept 就不指定 image/png，而指定可处理的 image/gif 和 image/jpeg 等图片类型。

若想要给显示的媒体类型增长优先级，则使用 q= 来额外表示权重值 1，用分号（;）进行分隔。权重值 q 的范围是 0~1（可精确到小数点 后 3 位），且 1 为最大值。不指定权重 q 值时，默认权重为 q=1.0。

6.4.2 Accept-Charset

Accept-Charset: iso-8859-5, unicode-1-1;q=0.8

Accept-Charset 首部字段可用来通知服务器用户代理支持的字符集及 字符集的相对优先顺序。另外，可一次性指定多种字符集。与首部字 段 Accept 相同的是可用权重 q 值来表示相对优先级。

该首部字段应用于内容协商机制的服务器驱动协商。

Accept-Encoding

Accept-Encoding: gzip, deflate

Accept-Encoding 首部字段用来告知服务器用户代理支持的内容编码及 内容编码的优先级顺序。可一次性指定多种内容编码。

• gzip

  由文件压缩程序 gzip（GNU zip）生成的编码格式 （RFC1952），采用 Lempel-Ziv 算法（LZ77）及 32 位循环冗余 校验（Cyclic Redundancy Check，通称 CRC）。

• compress

  由 UNIX 文件压缩程序 compress 生成的编码格式，采用 LempelZiv-Welch 算法（LZW）。

• deflate

  组合使用 zlib 格式（RFC1950）及由 deflate 压缩算法 （RFC1951）生成的编码格式。

• identity

  不执行压缩或不会变化的默认编码格式

采用权重 q 值来表示相对优先级，这点与首部字段 Accept 相同。另 外，也可以使用星号（*）做为通配符，指定任意的编码格式。

6.4.4 Accept-Language

Accept-Language: zh-cn,zh;q=0.7,en-us,en;q=0.3

首部字段 Accept-Language 用来告知服务器用户代理可以处理的天然 语言集（指中文或英文等），以及天然语言集的相对优先级。可一次 指定多种天然语言集。

6.4.5 Authorization

Authorization: Basic dWVub3NlbjpwYXNzd29yZA==

首部字段 Authorization 是用来告知服务器，用户代理的认证信息（证 书值）。一般，想要经过服务器认证的用户代理会在接收到返回的 401 状态码响应后，把首部字段 Authorization 加入请求中。共用缓存 在接收到含有 Authorization 首部字段的请求时的操做处理会略有差 异。

.4.6 Expect

Expect: 100-continue

客户端使用首部字段 Expect 来告知服务器，指望出现的某种特定行 为。因服务器没法理解客户端的指望做出回应而发生错误时，会返回 状态码 417 Expectation Failed。

6.4.7 From

首部字段 From 用来告知服务器使用用户代理的用户的电子邮件地 址。一般，其使用目的就是为了显示搜索引擎等用户代理的负责人的 电子邮件联系方式。使用代理时，应尽量包含 From 首部字段（但 可能会因代理不一样，将电子邮件地址记录在 User-Agent 首部字段 内）。

6.4.8 Host

首部字段 Host 会告知服务器，请求的资源所处的互联网主机名和端 口号。Host 首部字段在 HTTP/1.1 规范内是惟一一个必须被包含在请求内的首部字段。

首部字段 Host 和以单台服务器分配多个域名的虚拟主机的工做机制 有很密切的关联，这是首部字段 Host 必须存在的意义。

6.4.9 If-Match

图：附带条件请求

形如 If-xxx 这种样式的请求首部字段，均可称为条件请求。服务器接 收到附带条件的请求后，只有判断指定条件为真时，才会执行请求。

If-Match: "123456"

首部字段 If-Match，属附带条件之一，它会告知服务器匹配资源所用 的实体标记（ETag）值。这时的服务器没法使用弱 ETag 值。（请参 照本章有关首部字段 ETag 的说明）

服务器会比对 If-Match 的字段值和资源的 ETag 值，仅当二者一致 时，才会执行请求。反之，则返回状态码 412 Precondition Failed 的响应。

还可使用星号（*）指定 If-Match 的字段值。针对这种状况，服务 器将会忽略 ETag 的值，只要资源存在就处理请求。

6.4.10 If-Modified-Since

If-Modified-Since: Thu, 15 Apr 2004 00:00:00 GMT

首部字段 If-Modified-Since，属附带条件之一，它会告知服务器若 IfModified-Since 字段值早于资源的更新时间，则但愿能处理该请求。 而在指定 If-Modified-Since 字段值的日期时间以后，若是请求的资源 都没有过更新，则返回状态码 304 Not Modified 的响应。

if-Modified-Since 用于确认代理或客户端拥有的本地资源的有效性。 获取资源的更新日期时间，可经过确认首部字段 Last-Modified 来确 定。

6.4.11 If-None-Match

首部字段 If-None-Match 属于附带条件之一。它和首部字段 If-Match 做用相反。用于指定 If-None-Match 字段值的实体标记（ETag）值与 请求资源的 ETag 不一致时，它就告知服务器处理该请求。

在 GET 或 HEAD 方法中使用首部字段 If-None-Match 可获取最新的资 源。所以，这与使用首部字段 If-Modified-Since 时有些相似。

6.4.12 If-Range

首部字段 If-Range 属于附带条件之一。它告知服务器若指定的 IfRange 字段值（ETag 值或者时间）和请求资源的 ETag 值或时间相一 致时，则做为范围请求处理。反之，则返回全体资源。

6.4.13 If-Unmodified-Since

If-Unmodified-Since: Thu, 03 Jul 2012 00:00:00 GMT

首部字段 If-Unmodified-Since 和首部字段 If-Modified-Since 的做用相反。它的做用的是告知服务器，指定的请求资源只有在字段值内指定的日期时间以后，未发生更新的状况下，才能处理请求。若是在指定 日期时间后发生了更新，则以状态码 412 Precondition Failed 做为响应返回。

6.4.14 Max-Forwards

Max-Forwards: 10

经过 TRACE 方法或 OPTIONS 方法，发送包含首部字段 MaxForwards 的请求时，该字段以十进制整数形式指定可通过的服务器最 大数目。服务器在往下一个服务器转发请求以前，Max-Forwards 的 值减 1 后从新赋值。当服务器接收到 Max-Forwards 值为 0 的请求 时，则再也不进行转发，而是直接返回响应。

使用 HTTP 协议通讯时，请求可能会通过代理等多台服务器。途中， 若是代理服务器因为某些缘由致使请求转发失败，客户端也就等不到 服务器返回的响应了。对此，咱们无从可知。

能够灵活使用首部字段 Max-Forwards，针对以上问题产生的缘由展 开调查。因为当 Max-Forwards 字段值为 0 时，服务器就会当即返回 响应，由此咱们至少能够对以那台服务器为终点的传输路径的通讯状 况有所把握。

6.4.15 Proxy-Authorization

Proxy-Authorization: Basic dGlwOjkpNLAGfFY5

接收到从代理服务器发来的认证质询时，客户端会发送包含首部字段 Proxy-Authorization 的请求，以告知服务器认证所须要的信息。

这个行为是与客户端和服务器之间的 HTTP 访问认证相相似的，不一样 之处在于，认证行为发生在客户端与代理之间。客户端与服务器之间 的认证，使用首部字段 Authorization 可起到相同做用。有关 HTTP 访 问认证，后面的章节会做详尽阐述。

6.4.16 Range

Range: bytes=5001-10000

对于只需获取部分资源的范围请求，包含首部字段 Range 便可告知服 务器资源的指定范围。上面的示例表示请求获取从第 5001 字节至第 10000 字节的资源。

接收到附带 Range 首部字段请求的服务器，会在处理请求以后返回状 态码为 206 Partial Content 的响应。没法处理该范围请求时，则会返 回状态码 200 OK 的响应及所有资源。

6.4.17 Referer

Referer: http://www.hackr.jp/index.htm

首部字段 Referer 会告知服务器请求的原始资源的 URI。

客户端通常都会发送 Referer 首部字段给服务器。但当直接在浏览器 的地址栏输入 URI，或出于安全性的考虑时，也能够不发送该首部字 段。

由于原始资源的 URI 中的查询字符串可能含有 ID 和密码等保密信 息，要是写进 Referer 转发给其余服务器，则有可能致使保密信息的 泄露。

6.4.18 TE

(略)

6.4.19 User-Agent

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0.1

首部字段 User-Agent 会将建立请求的浏览器和用户代理名称等信息传 达给服务器。

6.5 响应首部字段

响应首部字段是由服务器端向客户端返回响应报文中所使用的字段， 用于补充响应的附加信息、服务器信息，以及对客户端的附加要求等 信息。

6.5.1 Accept-Ranges

Accept-Ranges: bytes

首部字段 Accept-Ranges 是用来告知客户端服务器是否能处理范围请 求，以指定获取服务器端某个部分的资源。

可指定的字段值有两种，可处理范围请求时指定其为 bytes，反之则 指定其为 none。

6.5.2 Age

Age: 600

首部字段 Age 能告知客户端，源服务器在多久前建立了响应。字段值 的单位为秒。

若建立该响应的服务器是缓存服务器，Age 值是指缓存后的响应再次 发起认证到认证完成的时间值。代理建立响应时必须加上首部字段 Age。

6.5.3 ETag

ETag: "82e22293907ce725faf67773957acd12"

首部字段 ETag 能告知客户端实体标识。它是一种可将资源以字符串 形式作惟一性标识的方式。服务器会为每份资源分配对应的 ETag 值。

另外，当资源更新时，ETag 值也须要更新。生成 ETag 值时，并无 统一的算法规则，而仅仅是由服务器来分配。

6.5.4 Location

Location: http://www.usagidesign.jp/sample.html

使用首部字段 Location 能够将响应接收方引导至某个与请求 URI 位置 不一样的资源。

基本上，该字段会配合 3xx ：Redirection 的响应，提供重定向的 URI。

几乎全部的浏览器在接收到包含首部字段 Location 的响应后，都会强 制性地尝试对已提示的重定向资源的访问。

6.5.5 Proxy-Authenticate

Proxy-Authenticate: Basic realm="Usagidesign Auth"

首部字段 Proxy-Authenticate 会把由代理服务器所要求的认证信息发送给客户端。

它与客户端和服务器之间的 HTTP 访问认证的行为类似，不一样之处在 于其认证行为是在客户端与代理之间进行的。而客户端与服务器之间 进行认证时，首部字段 WWW-Authorization 有着相同的做用。有关 HTTP 访问认证，后面的章节会再进行详尽阐述。

6.5.6 Retry-After

Retry-After: 120

首部字段 Retry-After 告知客户端应该在多久以后再次发送请求。主要 配合状态码 503 Service Unavailable 响应，或 3xx Redirect 响应一块儿使用。

字段值能够指定为具体的日期时间（Wed, 04 Jul 2012 06：34：24 GMT 等格式），也能够是建立响应后的秒数。

6.5.7 Server

Server: Apache/2.2.17 (Unix)

首部字段 Server 告知客户端当前服务器上安装的 HTTP 服务器应用程 序的信息。不仅仅会标出服务器上的软件应用名称，还有可能包括版 本号和安装时启用的可选项。

Server: Apache/2.2.6 (Unix) PHP/5.2.5

6.5.8 Vary

Vary: Accept-Language

首部字段 Vary 可对缓存进行控制。源服务器会向代理服务器传达关 于本地缓存使用方法的命令。

从代理服务器接收到源服务器返回包含 Vary 指定项的响应以后，若 再要进行缓存，仅对请求中含有相同 Vary 指定首部字段的请求返回 缓存。即便对相同资源发起请求，但因为 Vary 指定的首部字段不相 同，所以必需要从源服务器从新获取资源。

6.5.9 WWW-Authenticate

WWW-Authenticate: Basic realm="Usagidesign Auth"

首部字段 WWW-Authenticate 用于 HTTP 访问认证。它会告知客户端 适用于访问请求 URI 所指定资源的认证方案（Basic 或是 Digest）和 带参数提示的质询（challenge）。状态码 401 Unauthorized 响应中， 确定带有首部字段 WWW-Authenticate。

6.6 实体首部字段

实体首部字段是包含在请求报文和响应报文中的实体部分所使用的首 部，用于补充内容的更新时间等与实体相关的信息。

6.6.1 Allow

Allow: GET, HEAD

首部字段 Allow 用于通知客户端可以支持 Request-URI 指定资源的所 有 HTTP 方法。当服务器接收到不支持的 HTTP 方法时，会以状态码 405 Method Not Allowed 做为响应返回。与此同时，还会把全部能支 持的 HTTP 方法写入首部字段 Allow 后返回。

6.6.2 Content-Encoding

Content-Encoding: gzip

首部字段 Content-Encoding 会告知客户端服务器对实体的主体部分选 用的内容编码方式。内容编码是指在不丢失实体信息的前提下所进行 的压缩。

6.6.3 Content-Language

Content-Language: zh-CN

首部字段 Content-Language 会告知客户端，实体主体使用的天然语言 （指中文或英文等语言）。

6.6.4 Content-Length

Content-Length: 15000

首部字段 Content-Length 代表了实体主体部分的大小（单位是字 节）。对实体主体进行内容编码传输时，不能再使用 Content-Length 首部字段。因为实体主体大小的计算方法略微复杂，因此在此再也不展 开。读者若想一探究竟，可参考 RFC2616 的 4.4。

6.6.5 Content-Location

Content-Location: http://www.hackr.jp/index-ja.html

首部字段 Content-Location 给出与报文主体部分相对应的 URI。和首 部字段 Location 不一样，Content-Location 表示的是报文主体返回资源对应的 URI。

6.6.6 Content-MD5

(略)

6.6.7 Content-Range

Content-Range: bytes 5001-10000/10000

针对范围请求，返回响应时使用的首部字段 Content-Range，能告知客 户端做为响应返回的实体的哪一个部分符合范围请求。字段值以字节为 单位，表示当前发送部分及整个实体大小。

6.6.8 Content-Type

Content-Type: text/html; charset=UTF-8

首部字段 Content-Type 说明了实体主体内对象的媒体类型。和首部字 段 Accept 同样，字段值用 type/subtype 形式赋值。

参数 charset 使用 iso-8859-1 或 euc-jp 等字符集进行赋值。

6.6.9 Expires

Expires: Wed, 04 Jul 2012 08:26:05 GMT

首部字段 Expires 会将资源失效的日期告知客户端。缓存服务器在接 收到含有首部字段 Expires 的响应后，会以缓存来应答请求，在 Expires 字段值指定的时间以前，响应的副本会一直被保存。当超过 指定的时间后，缓存服务器在请求发送过来时，会转向源服务器请求 资源。

源服务器不但愿缓存服务器对资源缓存时，最好在 Expires 字段内写 入与首部字段 Date 相同的时间值。

可是，当首部字段 Cache-Control 有指定 max-age 指令时，比起首部字段 Expires，会优先处理 max-age 指令。

6.6.10 Last-Modified

Last-Modified: Wed, 23 May 2012 09:59:55 GMT

首部字段 Last-Modified 指明资源最终修改的时间。通常来讲，这个 值就是 Request-URI 指定资源被修改的时间。但相似使用 CGI 脚本进 行动态数据处理时，该值有可能会变成数据最终修改时的时间。

6.7 为 Cookie 服务的首部字段

下面的表格内列举了与 Cookie 有关的首部字段。

表 6-8：为 Cookie 服务的首部字段

首部字段名	说明	首部类型
Set-Cookie	开始状态管理所使用的Cookie信息	响应首部字段
Cookie	服务器接收到的Cookie信息	请求首部字段

6.7.1 Set-Cookie

Set-Cookie: status=enable; expires=Tue, 05 Jul 2011 07:26:31 GMT; path=/; domain=.hackr.jp;

当服务器准备开始管理客户端的状态时，会事先告知各类信息。

下面的表格列举了 Set-Cookie 的字段值

属性	说明
NAME=VALUE	赋予 Cookie 的名称和其值（必需项）
expires=DATE	Cookie 的有效期（若不明确指定则默认为浏览器关闭前为止）
path=PATH	将服务器上的文件目录做为Cookie的适用对象（若不指定则默认为文档所在的文件目录）
domain=域名	做为 Cookie 适用对象的域名 （若不指定则默认为建立 Cookie的服务器的域名）
Secure	仅在 HTTPS 安全通讯时才会发送 Cookie
HttpOnly	加以限制，使 Cookie 不能被 JavaScript 脚本访问

expires 属性

Cookie 的 expires 属性指定浏览器可发送 Cookie 的有效期。

当省略 expires 属性时，其有效期仅限于维持浏览器会话（Session） 时间段内。这一般限于浏览器应用程序被关闭以前。

另外，一旦 Cookie 从服务器端发送至客户端，服务器端就不存在可 以显式删除 Cookie 的方法。但可经过覆盖已过时的 Cookie，实现对 客户端 Cookie 的实质性删除操做。

path 属性

Cookie 的 path 属性可用于限制指定 Cookie 的发送范围的文件目录。 不过另有办法可避开这项限制，看来对其做为安全机制的效果不能抱 有期待。

domain 属性

经过 Cookie 的 domain 属性指定的域名可作到与结尾匹配一致。比 如，当指定 example.com 后，除 example.com 之外，www.example.com 或 www2.example.com 等均可以发送 Cookie。

所以，除了针对具体指定的多个域名发送 Cookie 之 外，不指定domain 属性显得更安全

secure 属性

Cookie 的 secure 属性用于限制 Web 页面仅在 HTTPS 安全链接时，才 能够发送 Cookie。

发送 Cookie 时，指定 secure 属性的方法以下所示。

Set-Cookie: name=value; secure

以上例子仅当在 https://www.example.com/（HTTPS）安全链接的状况 下才会进行 Cookie 的回收。也就是说，即便域名相同， http://www.example.com/（HTTP）也不会发生 Cookie 回收行为。

当省略 secure 属性时，不论 HTTP 仍是 HTTPS，都会对 Cookie 进行 回收。

HttpOnly 属性

Cookie 的 HttpOnly 属性是 Cookie 的扩展功能，它使 JavaScript 脚本 没法得到 Cookie。其主要目的为防止跨站脚本攻击（Cross-site scripting，XSS）对 Cookie 的信息窃取。

发送指定 HttpOnly 属性的 Cookie 的方法以下所示。

Set-Cookie: name=value; HttpOnly

经过上述设置，一般从 Web 页面内还能够对 Cookie 进行读取操做。 但使用 JavaScript 的 document.cookie 就没法读取附加 HttpOnly 属性后的 Cookie 的内容了。所以，也就没法在 XSS 中利用 JavaScript 劫持 Cookie 了。

虽然是独立的扩展功能，但 Internet Explorer 6 SP1 以上版本等当下的 主流浏览器都已经支持该扩展了。另外顺带一提，该扩展并不是是为了 防止 XSS 而开发的。

6.7.2 Cookie

Cookie: status=enable

首部字段 Cookie 会告知服务器，当客户端想得到 HTTP 状态管理支 持时，就会在请求中包含从服务器接收到的 Cookie。接收到多个 Cookie 时，一样能够以多个 Cookie 形式发送。

6.8 其余首部字段

(略)