图解HTTP六：HTTP 首部

6.1 HTTP 报文首部

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

请求报文

响应中的HTTP报文包含HTTP版本标识、状态码字段（包括数字和原因短语两部分）以及头部字段的三部分。

请求报文

6.2 HTTP 首部字段

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

HTTP 标头字段在构建 HTTP 传输实体时扮演着关键角色。无论发起请求还是处理响应，在 HTTP 协议驱动的应用交流中都会涉及标头字段的使用。其主要功能在于传输附加的关键信息。通过提供报文主体大小、使用的语言版本以及认证信息等细节信息。

6.2.2 HTTP 首部字段结构

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

首部字段名: 字段值

例如，在 HTTP 首部中使用 Content-Type 作为描述 数据内容属性 的字段

Content-Type: text/html

以示例为例，在本场景中使用 ... 标识符表示参数类型说明：在该示例中，contentType 字段名称对应于字符串为 text/html 的参数类型。此外，请注意单个 HTTP 首部字段可能具有多个值配置项（例如：User-Agent, Date, Referrer 等）。

Keep-Alive: timeout=15, max=100

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 End-to-end 首部和 Hop-by-hop 首部

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

• 端到端首部（End-to-end Header）：此类别中的特定头部负责将请求/响应的数据转发给最终接收方，并会在缓存层生成的响应中被包含和返回给下一个处理层。
  • 逐跳首部（Hop-by-hop Header）：此类别的头部仅用于单次数据传输；这些数据不会继续被后续节点处理或者转发；需要注意的是，在HTTP/1.1及更高版本中，默认情况下不支持这种机制，默认情况下默认情况下默认情况下默认情况下默认情况下默认情况下

以下列举了HTTP/1.1中的分段头信息。不包括这8项的是端到端头信息。

• 连接
• 会话维持
• 代理认证
• 授权协议
• 传输尾部信息
• 升级机制
• 传输编码

6.3 HTTP/1.1 通用首部字段

6.3.1 Cache-Control

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

首部字段 Cache-Control 能够控制缓存的行为

该指令的参数具有可选项性，并且各指令之间可通过逗号分隔。位于请求头部的Cache-Control指令不仅用于响应处理，并且在请求阶段也可被调用以优化性能。

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

表 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时，则清楚地表明其他人也可以使用缓存。

Cache-Control: private

当设置 private 指令时，系统响应仅针对该特定用户的请求，并与 public 指令的行为形成对比。缓存服务器会将资源缓存服务提供给该特定用户；而对于接受其他用户请求的代理服务器来说，则不会回应缓存相关查询。

no-cache 指令

Cache-Control: no-cache

no-cache 指令的设计初衷是为了过滤掉缓存系统中可能失效的数据项。
当客户端提交包含 no-cache 指令的请求时，则表明该客户端不会接受来自缓存服务器已过期的内容。
因此，“中间”阶段的缓存服务器必须将客户端的所有请求转发给源服务器进行处理。
若源服务器返回包含 no-cache 信息的响应，则缓存服务器不得对该资源进行任何存储行为。
源服务器将彻底停止验证缓存服务器所报资源的有效性状态，并禁止其完成任何关于响应资源存储的任务。

Cache-Control: no-cache=Location

当服务器返回一个响应时，在其Header中的Cache-Control头字段中的no/cache头域如果具体指定了某个参数值，则客户端接收到带有该特定no/cache头域参数值的相应回应数据后将无法利用缓存机制。换句话说，在没有指明no/cache头域的具体数值的情况下，则允许客户端进行缓存操作。只有在这种情况下（即仅当Response指令中有相应的设置），才能定义这一行为。

控制可执行缓存的对象的指令：no-store 指令

Cache-Control: no-store

当采用 no-store 指令 1 时, 显示请求及其对应回应, 或回应中包含敏感信息. 因而, 此指令指示缓存不得在本地存储请求或回应的任何部分.

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

1. s-maxage 指令

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

s-maxage指令的作用与max-age指令具有相似性；它们的不同之处在于s-maxage指令专用于供多位用户共享的公共缓存服务器。具体来说，针对向同一用户持续返回响应的服务器而言，这种指令并没有任何效果。此外，在应用了s-maxage指令之后，则会导致对Expires首部字段以及max-age指令的相关处理被直接忽略

2. max-age 指令

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

当客户端发送的请求中包含 max-age 指令时，如果判定缓存资源的缓存时间数值比指定时间的数值更小，那么客户端就接收缓存的资源。另外，当指定 max-age 值为 0，那么缓存服务器通常需要将请求转发给源服务器。
当服务器返回的响应中包含 max-age 指令时，缓存服务器将不对资源的有效性再作确认，而 max-age 数值代表资源保存为缓存的最长时间。

3. min-fresh 指令

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

min-fresh 指令规定缓存服务器必须提供未过时的缓存资源。例如，在设置 min-fresh 为 60 秒后，任何超过该时间的资源将无法作为响应被返回。

4. max-stale 指令

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

使用 max-stale 用于指示缓存资源的状态，在资源已过期的情况下仍能正常接收请求。当指令未明确给出参数值时，则无论经过多长时间都会被客户端正常处理响应；但若指令中明确指定了具体的数值，则只有在该数值仍在 max-stale 指定的时间范围内才会被客户端接受处理。

5. only-if-cached 指令

Cache-Control: only-if-cached

该指令用于指示客户端仅当其目标资源已存在缓存服务器本地缓存时才进行请求。换句话说,该指令迫使缓存服务器不再加载响应并放弃对资源有效性的验证。当请求至缓存服务器而本地缓存未响应时系统将返回状态码 504 Gateway Timeout。

6. must-revalidate 指令

Cache-Control: must-revalidate

采用 must-revalidate 指令后进行响应缓存的有效性验证操作后会触发相关机制以确保缓存数据的一致性完整性。当代理无法与目标服务器建立连接以获取新数据时 缓存将发送给客户端一个 504（Gateway Timeout）状态码指示从而触发客户端重新发起请求机制以获取最新数据。此外 使用 must-revalidate指令会导致原有 max-stale 头部指令失效 即使在请求头部分析中已经设置了 max-stale 参数也不会生效

7. proxy-revalidate 指令

Cache-Control: proxy-revalidate

proxy-revalidate 指令规定为：所有缓存服务器在接收到来自客户端带有该指令的请求并准备返回响应之前，必须再次确认缓存数据的有效性。

8. 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 成功地实现了这一指令的添加。当缓存服务器无法识别该新指令时会直接忽略它。基于此可知，在能够识别该指令的缓存服务器上才会显现出其意义。

6.3.2 Connection

Connection 首部字段具备如下两个作用。

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

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

当客户端提交请求并服务器反馈响应内容时，可以通过采用Connection头字段来避免由代理层转发其相关的Hop-by-hop头部信息。

• 管理持久连接

Connection: close

在HTTP/1.1协议中，默认情况下所有会话连接均为 persistence 性连接。因此，在持续性连接上客户端将发起连续的请求。当服务器希望终止当前会话时，则应在 Connection 头字段中设置其值为 Close。

Connection: Keep-Alive

HTTP/1.1 之前的 HTTP 版本（协议）默认设置为非持久连接。为了实现旧版本（早期版本）HTTP 协议下的长时间数据传输（持续连接），必须将 Connection 头域设置为 Keep-Alive。如上图①所示，在客户端发送请求给服务器时（即当客户端发送请求给服务器时），服务器端会在响应头中添加首部字段 Keep-Alive 和 Connection 以实现上述效果。

6.3.3 Date

字段 Date 显示了创建 HTTP 请求的时间信息。协议遵循 RFC 1123 中定义的时间格式规定。例如，在 RFC 822 标准中详细描述了此类编码方法。

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

6.3.4 Trailer

Trailer字段将明确列出后续报文中所有相关的首部字段信息。这些字段特别适用于采用HTTP/1.1协议进行分块编码的情况。

6.3.5 Transfer-Encoding

数据包传输中的编码方案由 Transfer-Encoding 字符串字段定义。在 HTTP/1.1 标准下，分块编码方法仅适用于分段式的数据传输。

6.3.6 Upgrade

Upgrade字段用于判断HTTP协议及其他协议是否支持使用更高版本的协议进行通信；其参数值用来指定一个完全不同类型的通信协议。

在示例图中,头部Upgrade字段被配置为TLS/1.0。请特别注意此场景中两处头部字段之间的对应关系,在此情况下Connection字段的值等于Upgrade。因此,在配置时必须同时设置Connection:Upgrade。当客户端发送包含Upgrade头部字段的数据包时，默认会返回带有状态码101切换协议切换信息的回答文档。

6.3.7 Via

由于首部字段Via旨在追踪客户端与服务器之间的请求及响应报文传输的具体路径，在实际应用中当报文经过代理或网关时，在首部字段Via中附加该服务器的相关信息以实现路径记录功能。其不仅用于追踪报文的传输路径还可有效防止因多次转发导致的请求回环现象的发生因此，在经过代理时必须附加该首部字段内容以确保数据完整性与系统安全性得到保障

Via 头部用于跟踪传输路径，在TRACE 方法中常配合使用。例如，在agent server接收来自trace method发送过来的request（其中Max-Forwards字段设置为0）时, agent server将不再转发此request.在此情况下, agent server会在response头中添加自身相关信息后返回相应response.

6.3.9 Warning

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

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

表 6-7： HTTP/1.1 警告码

警告码	警告内容	说明
110	Response is stale（响应已过期）	代理返回已过期的资源
111	Revalidation failed（再验证失败）	代理再验证资源有效性时失败（服务器无法到达等原因）
112	Disconnection operation （断开连接操作）	代理与互联网连接被故意切断
113	Heuristic expiration（试探性过期）	响应的使用期超过24小时（有效缓存的设定时间大于24小时的情况下）
199	Miscellaneous warning（杂项警告）	任意的警告内容
214	Transformation applied（使用了转换）	代理对内容编码或媒体类型等执行了某些处理时
299	Miscellaneous persistent warning（持久杂项警告）	任意的警告内容

6.4 请求首部字段

请求首部字段是客户端向服务器传输的报文中使用的字段参数，在补充和说明请求内容的同时包含了客户端相关信息以及与响应结果相关的重要程度等各项指标

6.4.1 Accept

允许客户端向服务器发送Header头字段以通知其支持的 media 格式及其 priority 设置。 可使用 type/subtype 这种形式同时指定多个 media 格式。 下面将举例说明几种常见的 media 类型和它们的应用场景。

• 文本类文件：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 等

若希望提升显示媒体类型的优先级，则可通过 q= 参数来指定权重值；这些参数之间需以分号 (;) 进行分隔。其取值范围为 0 至 1（精确至小数点后三位），其中最大取值为 1。若未指定 q 值，默认设置为 q=1.0；当服务器返回多种内容时，默认会优先输出具有最高权重的媒体类型

6.4.2 Accept-Charset

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

Accept-Charset 头条信息用于指示客户端设备代理所支持的各种字符编码及其优先顺序。此外，在同一个 Accept 头条信息中可以同时定义多个字符编码方案。这类似于在 Accept 头条信息中使用 q 权重值来确定不同协议或格式的相对重要程度。此参数主要用于指导服务器在协商内容格式时依据客户端代理设置的相关偏好进行调整。

6.4.3 Accept-Encoding

Accept-Encoding: gzip, deflate

Accept-Encoding字段用于指示服务器用户代理支持的内容编码及其排列顺序，并允许一次性指定多种不同的内容编码。举例说明几种常见的Content-Encoding值。

• gzip: Based on the gzip (GNU zip) file compression program, this encoding format (as defined in RFC 1952) utilizes the LZ77 algorithm along with a 32-bit cyclic redundancy check (Cyclic Redundancy Check, commonly referred to as CRC).
• compress: This encoding format is generated by the UNIX file compression program and employs the LZW algorithm.
• deflate: This format combines the use of the zlib format (as specified in RFC 1950) and the compression algorithm defined in RFC 1951.
• identity: The default compression format that does not perform compression or remains unchanged.

以权重 q 值的方式标记相对优先级，则与首部字段 Accept 保持一致；此外，在编码规范上也可采用星号（*）进行定位操作

6.4.4 Accept-Language

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

AcceptLanguage字段用于告知服务器用户的用户代理能够处理的不同语言类型（如汉语或英语等），并标明这些语言类型的重要性程度。允许多种格式指定支持的语言类型。与Accept字段相同的是基于权重值q来确定重要性顺序。当客户端访问包含汉语版本的内容时会请求对应的语言版本；如果未提供汉语版本则会发送英语版本的回答

6.4.5 Authorization

Authorization: Basic dWVub3NlbjpwYXNzd29yZA==

头部字段Authorization用于指示客户端的身份认证信息（即证书参数）。通常情况下，在客户端接收到服务器返回的HTTP 401错误响应后会将此头部字段包含在请求中。

6.4.6 Expect

客户通过首部字段Expect向服务器发送指示以预期特定行为的发生。
当服务器未能正确解析客户端的Expect请求时，
将返回状态码417 Expectation Failed。

6.4.7 From

该字段从（From）标识为发送邮件给服务器所使用的代理用户的电子邮箱地址。通常情况下，则该字段的主要作用是为了表明搜索引擎等代理机构的负责人使用的电子邮箱联系方式。

6.4.8 Host

图：虚拟主机运行在同一个 IP 上，因此使用首部字段 Host 加以区分

首部字段 Host 会表明服务器所处理的请求所处的位置及其对应端口号。根据HTTP/1.1规范规定，在所有请求中均有必要包含该首部字段Host。该首部字段Host不仅与单台服务器绑定多个域名的工作机制紧密相连，在其存在下确保了网络通信的有效性。
在HTTP协议中规定，在所有请求数量较多的情况下都会采用多线程技术来提高处理效率。因此，在此情况下通常会对各个进程进行隔离处理以保证系统的稳定性和可靠性。
在实际应用中我们通常会将不同类型的URL配置到不同的虚拟主机上以便于更好地管理维护工作。这样既能保证每个域名都能正常访问又能避免因地址冲突导致的服务中断问题。

6.4.9 If-Match

形如 If-xxx 格式的首部字段都可被视为条件请求。当服务器接收带有附加条件的请求数时，在确认指定条件成立的情况下才会发起响应。

服务器将核验If-Match字段值与资源的ETag值；只有在两者一致时才会发起请求。如果不符合条件则将返回412 Precondition Failed的状态码响应。

6.4.10 If-Modified-Since

当服务器返回响应头中的If-Modified-Since字段时，在指定的时间点之后如果资源发生更新，则服务器将接受请求。

作为附带的一个条件之一，“If-Modified-Since”字段会通知服务器，在指定字段值早于资源上次更新的时间时是否能够处理此请求。而当指定的时间是在资源上次更新之后，并且对应的资源没有发生修改，则返回状态码 304 Not Modified 的响应。

6.4.11 If-None-Match

当且仅当If-None-Match头部字段的设置为ETag时不处理该请求；其作用与If-Match头部字段相反

If-None-Match字段属于附加条件之一。它与If-Match字段功能相反。当If-None-Match字段中的实体标记（ETag）值与请求资源的ETag不一致时，则会通知服务器处理该请求。

6.4.12 If-Range

第一部字段If-Range被视为一个附加条件。它指示服务器在指定的If-Range字段值（ETag值或时间）与请求资源的ETag值或时间相同时，则被视为范围请求处理；相反地，则返回所有资源。

在缺少If-Range首部字段的情况下进行请求发送分析：当服务器端的资源发生更新时，在这种情况下客户端持有资源中的部分数据也会随之失效。可被视为无效的前提条件的是范围请求。此时服务器将暂时返回预置状态码412 Precondition Failed以达到催促客户端重新发送请求的目的。相较而言，则需要耗费双倍的时间与精力。

6.4.13 If-Unmodified-Since

头部字段If-Unmodified-Since与头部字段If-Modified-Since的功能相反。其主要作用是告知服务器，在特定请求资源中仅当指定期望更新的时间范围内的最新状态且未发生变更的情况下才能执行请求操作。一旦在指定期望更新的时间范围之后发生修改，则会返回412 Precondition Failed的状态码作为响应返回。

6.4.14 Max-Forwards

每次转发数值减 1。当数值变 0 时返回响应

当采用TRACE方法或OPTIONS方法发送包含首部字段Max-Forwards的请时时,该字段采用十进制整数形式指定可经过的服务器最大数目.在准备将请求数字转发至下一个服务器的过程中,前一阶段Max-Forwards值递减并重新赋值.若接收方接收到Max-Forwards值为零的请求数字,则不再转发此请求数字而是直接返回响应.

6.4.15 Proxy-Authorization

Proxy-Authorization: Basic dGlwOjkpNLAGfFY5

当客户方接收到来自代理方的认证询问时，在其请求头信息中包含指定的Proxy-Authorization字段以告知目标服务器所需的验证信息。这种行为在本质上类似于客户方与服务方之间的HTTP身份验证过程（简称HTTP访问认证），其不同之处在于该过程发生于客户方与代理方之间。而当客户方向其目标服务器发起访问请求时，则通过携带指定首部字段Authorization来实现类似的验证功能（或称为身份验证）。这种机制允许在客户方和目标服务方之间完成必要的身份验证流程而不必直接暴露敏感信息到中间环节。

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

该字段会指示服务器请求的相关原始资源的信息。一般而言，在网页开发中我们都会向服务器传递该字段。然而，在某些情况下（例如）当用户直接在浏览器地址栏输入该URI或者出于安全考虑时，则可以选择不发送该字段。
其中查询字符串可能包含诸如身份标识符和密码等敏感信息。若将这些信息通过Referer转发至其他服务器，则可能导致敏感数据泄露。

6.4.18 TE

TE: gzip, deflate;q=0.5

字段 TE 会指示服务器客户端如何处理响应的传输编码方式及其优先级。它与字段 AcceptEncoding 功能非常类似，并主要用于传输编码。

6.4.19 User-Agent

首字段 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会被前端发送给客户端用来识别实体信息。它是一种通过字符串唯一表示资源状态的方法。服务器会根据每份资源的具体信息自动生成对应的ETag值。
此外，在资源发生变更时, 相应的ETag值也会随之更新. 生成ETag值的过程并不遵循统一的规则, 并主要由服务器来负责生成和管理这些标识。

当资源被缓存时会分配唯一标识符。举例来说，在使用中文版本浏览器访问http://www.google.com/时会返回对应该语言版本的资源；而在使用英文版本浏览器访问该地址时则会返回对应英文版本的资源。两者具有相同的URI标识符, 因此仅凭借URI来指定缓存位置存在较大困难。在下载过程中发生断开连接并重新尝试链接的情况下, 通常依据ETag值来确定具体 resources的位置。

强 ETag 值和弱 Tag 值
ETag 中有强 ETag 值和弱 ETag 值之分。
强 ETag 值
不论实体发生多么细微的变化都会显著地改变其值。

ETag: “usagi-1234”

弱 ETag 值
指示资源是否相同的元数据字段（WETag）。仅用于指示资源是否发生根本性变化。当资源发生根本性变化导致差异出现时，则会更新ETag值。此时，在字段值的起始位置会附加W/标识符。

ETag: W/“usagi-1234”

6.5.4 Location

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

通过首部字段 Location 的传输机制，在服务器端接收方能够发送到特定的 URL 地址。该字段通常与 HTTP 重定向响应中的 3xx 状态码相关联。大多数主流浏览器在接收到包含 Location 字段的响应时，默认会尝试访问已被指定的重定向目标。

6.5.5 Proxy-Authenticate

Proxy-Authenticate: Basic realm=“Usagidesign Auth”

Proxy-Authenticate字段负责将来自代理服务器的身份验证请求发送给客户端。其行为类似于客户端和服务器之间的身份验证过程，并且这种行为仅限于客户端与代理服务器之间进行。

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: Accept-Language

其中首部字段 Vary 具有调节缓存内容的作用，并由源服务器向代理发送相应的指令以指示其如何管理本地存储。当源 server 收到 proxy server 返回包含指定 vary 首符的信息后, 若再次尝试获取 cache 内容, 则仅在客户端发送与当前 vary 指定位相同的前缀时提供 cache 响应。即使向同一资源发送不同 vary 指定位信息的请求，则必须从 source server 重新获取该资源。

6.5.9 WWW-Authenticate

WWW-Authenticate: Basic realm=“Usagidesign Auth”

首部字段WWW-Authenticate负责执行HTTP访问认证。该字段指示客户端针对访问请求URI所指定资源的认证方案（如Basic或Digest），以及相关的挑战。
在状态码401Unauthorized响应头程中，默认包含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 表明客户端服务器对实体主体部分所采用的内容编码方式。内容编码指的是在确保实体信息完整性的前提下进行的数据压缩过程。主要采用以下四种方式进行编码.

• gzip
• compress
• deflate
• identity

6.6.3 Content-Language

Content-Language: zh-CN

该字段表示客户端所处理信息的使用语言（主要为中文或英文等语言）。

6.6.4 Content-Length

Content-Length: 15000

首部字段 Content-Length 表明了实体主体部分的大小（单位是字节）。

6.6.5 Content-Location

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

内容位置字段 Content-Location 用于标识报文主体应返回资源的具体位置信息，并与首部字段 Location 区别在于前者明确指出资源的位置关系而后者仅表示存在资源关系。

6.6.6 Content-MD5

接收端会计算接收到的报文主体所携带的 MD5 管理数据，并将其与其内容校验码进行比对

Content-MD5: OGFkZDUwNGVhNGY3N2MxMDIwZmQ4NTBmY2IyTY==

Content-MD5 是由 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 的结构。

6.6.9 Expires

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

该字段'Expires'用于告知客户端资源的有效截止日期。当缓存服务器接收到包含首部字段'Expires'的响应时会对请求作出缓存回应直到有效期截止时间过后才会放弃缓存副本。收到相关请求信息后如果目标节点未及时回复就会向目标服务发起重头请求避免目标缓存节点过快地淘汰有效副本通常建议设置与首部字段'Date'相同的失效时间但若场景中同时存在'Hold until date'指令（即Cache-Control: max-age）则默认处理该指令而非expires项

6.6.10 Last-Modified

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

头部字段 Last-Modified 标识资源最后被修改的时间。通常情况下,该值即为 Request-URI 指定资源被修改的时间,但在采用 CGI 脚本进行动态数据处理时,该值可能会演变为数据最后被修改的时间

6.7 为 Cookie 服务的首部字段

Cookie 的运作方式负责实现用户的识别和状态管理。Web 网站利用 Web 浏览器存储到用户的计算机中的一些数据来管理其状态。接着一旦用户登录该 Web 网站时，则可通过通信手段获取已发送的 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;

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

表 6-9： 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 协议下安全连接时才会触发 Cookie 的回收机制。即即便域名相同，在 HTTP 协议下同样不会执行 Cookie 的回收操作。若省略 secure 属性，则无论是在 HTTP 还是 HTTPS 环境中都会执行 Cookie 的清除操作。

HttpOnly 字段
Cookie中的HttpOnly字段标识了一个扩展功能。该字段阻止了JavaScript从该源获取Cookie对象。其主要目的是抵御跨站脚本攻击（Cross-site scripting, XSS）以防止Cookie信息被盗取。如果要设置带有HttpOnly属性的Cookie，请参考以下步骤

Set-Cookie: name=value; HttpOnly

基于上述配置，在Web页面上仍可执行Cookie读取操作。然而，在JavaScript中的document.cookie则不具备获取带有HttpOnly属性后Cookie内容的能力。由此可见，在XSS攻击中就无法借助JavaScript来劫持Cookie进行干预。

6.7.2 Cookie

Cookie: status=enable

头部字段 Cookie 会告知服务器，在请求中包含从服务器接收的 Cookie。当客户端接收多个 Cookie 时，在响应中返回相应的 cookie 列表。

6.8 其他首部字段

• X-Frame-Options
• X-XSS-Protection
• DNT
• P3P

6.8.1 X-Frame-Options

X-Frame-Options: DENY

该响应头域中的X-Frame-Options字段属于HTTP响应头域，并用于由其他Web网站上的Frame标签来显示网站内容时起作用。该字段的主要功能在于防止点击劫持攻击（clickjacking）。它通过限制或移除不允许的内容来实现这一目标，并支持两种指定方式：允许所有内容通过和仅允许非框架化的内容通过。

• 不允许访问：阻止访问。
  • 不允许跨域脚本：仅在与之相同的网络层级下进行脚本检查。
    比如，在设置http://example.com/page.html为SAMEORIGIN的情况下，
    那么example.com上的某些元素将无法嵌入到该网页中，
    而同一个层级域内的元素则可以正常嵌入。

6.8.2 X-XSS-Protection

X-XSS-Protection: 1

该字段 X-XSS-Protection 作为 HTTP 应答头部的一部分存在。它旨在应对跨站脚本攻击（XSS）的一种防护措施，并用于配置浏览器对 XSS 攻击的防护选项。该字段 X-XSS-Protection 所支持设置的内容包括：

• 0 ：将 XSS 过滤设置成无效状态
• 1 ：将 XSS 过滤设置成有效状态

6.8.3 DNT

DNT: 1

DNT字段属于HTTP请求头部字段。其中DNT为Do Not Track的缩写,其作用是阻止信息收集行为,是一种避免精准广告追踪的方法。DNT字段可指定的值包括:

• 0 ：同意被追踪
• 1 ：拒绝被追踪

因首部字段 DNT 功能包含有效的支持功能，Web 服务器应对其做相应的支持工作。

6.8.4 P3P

P3P: CP= "CAO DSP LAW CUR-A ADM-a DEV-a TAI-a PSA-a PSD-a IVA-a IVD-a OUR BUS IND UNI COM NAV INT"

字段名称为P3P的属于HTTP标准中的头部字段。通过采用基于在线隐私偏好平台（The Platform for Privacy Preferences）的技术手段，可以使Web网站上用户的个人隐私信息仅限于程序可读取的形式以实现保护用户隐私的目标。在配置过程中，请按照以下操作步骤完成设置。

• 第一步：生成 P3P 私密设置
  • 第二步：在创建 P3P 私密对照文件的过程中，请确保将其命名为/w3c/p3p.xml
  • 第三步：基于 P3P 私密设置构建Compact 策略时，请将其发送至 HTTP 应答中