- 第6章 HTTP首部
- 6.1 HTTP报文首部
- 6.2 HTTP首部字段
- 6.2 HTTP/1.1 通用首部字段
- 6.4 请求首部字段
- 6.4.1 Accept
- 6.4.2 Accept-Charset
- 6.4.3 Accept-Encoding
- 6.4.4 Accept-Language
- 6.4.5 Authorization
- 6.4.7 From
- 6.4.8 Host
- 6.4.9 If-Match
- 6.4.10 If-Modified-Since
- 6.4.11 If-None-Match
- 6.4.12 If-Range
- 6.4.13 If-Unmodified-Since
- 6.4.14 Max-Forwards
- 6.4.15 Proxy-Authorization
- 6.4.16 Range
- 6.4.17 Referer
- 6.4.18 TE
- 6.4.19 User-Agent
- 6.5 响应首部字段
- 6.6 实体首部字段
- 6.7 为Cookie服务的首部字段
- 6.8 其他首部字段
第6章 HTTP首部
6.1 HTTP报文首部
HTTP报文首部,不区分大小写

6.2 HTTP首部字段
使用首部字段是为了给浏览器和服务器提供报文主体大小、所使用的语言、认证信息等内容
6.2.2 HTTP首部字段结构
首部字段名: 字段值(,字段值2,。。。)
尽量不要设置重复的首部字段,因为不同浏览器对重复处理的方式不同
6.2.3 4种HTTP首部字段类型
- 通用首部字段:请求and响应报文都会用的首部
- 请求首部字段:only request,补充了请求的附加内容、客户端信息、相应内容相关优先级等信息
- 响应首部字段:only response,补充了响应的内容
- 实体首部字段:针对实体部分使用的首部,补充了资源内容更新时间等与实体有关的信息
6.2.4 HTTP/1.1 首部字段一览
HTTP/1.1规范定义了47种首部字段
- 通用首部字段

- 请求首部字段

- 响应首部字段

- 实体首部字段

6.2.5 非HTTP/1.1首部字段
除了RFC2616种的47种,还有Cookie、Set-Cookie、Content-Disposition等在其他RFC中定义的首部字段
6.2.6 End-to-end首部和Hop-by-hop首部
HTTP 首部字段根据缓存代理和非缓存代理的行为,可以分为 2 种类型。
- 端到端首部 End-to-end Header
分在此类别中的首部会转发给请求 / 响应对应的最终接收目标,且必须保存在由缓存生成的响应中,另外规定它必须被转发。
- 逐跳首部 Hop-by-hop Header
分在此类别中的首部只对单次转发有效,会因通过缓存或代理而不再转发,有以下几个:

其他的都是端到端首部
6.2 HTTP/1.1 通用首部字段
6.3.1 Cache-Control

Cache-Control可用于请求和响应中,例子:
Cache-Control: private, max-age=0, no-cache
缓存请求指令:
| 指令 | 参数 | 说明 |
|---|---|---|
| no-cache | - | 强制向源服务器再次验证 |
| no-store | - | 不缓存请求或响应的任何内容 |
| max-age = [秒] | √ | 响应的最大Age值 |
| max-stale( = [秒] ) | 可省 | 接收已过期的响应 |
| min-fresh = [秒] | √ | 期望在指定时间内的响应仍有效 |
| no-transform | - | 代理不可更改媒体类型 |
| only-if-cached | - | 从缓存获取资源 |
| cache-extension | - | 新指令标记(token) |
缓存响应指令:
| 指令 | 参数 | 说明 |
|---|---|---|
| public | - | 可向任何方提供响应的缓存 |
| private | - | 尽享特定用户返回响应 |
| no-cache | - | 缓存前先确定有效性 |
| no-store | - | 不缓存请求或响应的任何内容 |
| no-transform | - | 代理不可改变媒体类型 |
| must-revalidate | - | 可缓存但必须再向源服务器进行确认 |
| proxy-revalidate | - | 要求中间缓存服务器对缓存的响应有效性进行再确认 |
| max-age=[秒] | √ | 响应的最大age值 |
| s-maxage=[秒] | √ | 公共缓存服务器响应的最大age值 |
| cache-extension | - | 新指令标记(token) |
下面逐一介绍,这个表示能否缓存的指令:
1. public(可缓存性)
Cache-Control: public
表明响应可以被任何对象(包括:发送请求的客户端,代理服务器,等等)缓存,即使是通常不可缓存的内容。(例如:1.该响应没有max-age指令或Expires消息头;2. 该响应对应的请求方法是 POST 。)
2. private(可缓存性)

表明响应只能被单个用户缓存,不能作为共享缓存(即代理服务器不能缓存它)。私有缓存可以缓存响应内容,比如:对应用户的本地浏览器。
3. no-cache(可缓存性)
Cache-Control: no-cache
在发布缓存副本之前,强制要求缓存把请求提交给原始服务器进行验证(协商缓存验证)。
防止从缓存中返回 过期 的资源,包括以下两个步骤:
- 客户端发送的请求中如果包含 no-cache 指令,则表示客户端将不会接收缓存过的响应。于是,“中间”的缓存服务器必须把客户端请求转发给源服务器。
- 如果服务器返回的响应中包含 no-cache 指令,那么缓存服务器不能对资源进行缓存。源服务器以后也将不再对缓存服务器请求中提出的资源有效性进行确认,且禁止其对响应资源进行缓存操作。
4. no-store(可缓存性)
Cache-Control: no-store
暗示请求或响应中包含机密信息,就是不进行缓存,该指令表示缓存不能在本地存储请求或响应的任一部分
5. s-maxage(到期)
和max-age相同,会覆盖max-age和expires,不同点是s-maxage只适用于供多位用户使用的公共缓存服务器,也就是说它对同一用户来说不会有任何作用
6. max-age(到期)
设置缓存存储的最大周期,超过这个时间缓存被认为过期(单位秒)。与Expires相反,时间是相对于请求的时间

当客户端发送的请求中包含 max-age 指令时,如果判定缓存资源的缓存时间数值比指定时间的数值更小,那么客户端就接收缓存的资源。 另外,当指定 max-age 值为 0,那么缓存服务器通常需要将请求转发给源服务器。 当服务器返回的响应中包含 max-age 指令时,缓存服务器将不对资源 的有效性再作确认,而 max-age 数值代表资源保存为缓存的最长时间。
应用 HTTP/1.1 版本的缓存服务器遇到同时存在 Expires 首部字段的情况时,会优先处理 max-age 指令,而忽略掉 Expires 首部字段。HTTP/1.0的缓存服务器则正好相反
7. min-fresh(到期)

表示客户端希望获取一个能在指定的秒数内保持其最新状态的响应
比如说min-fresh=60,表示过了60秒的资源都无法作为响应返回了
8. max-stale(到期)
Cache-Control: max-stale=3600
指示缓存资源,即使过期也可以接收,如果指定了参数,即使过期,只要仍处于 max-stale 指定的时间内,仍旧会被客户端接收
9. only-if-cached
表明客户端只接受已缓存的响应,并且不要向原始服务器检查是否有更新的拷贝。
10. must-revalidate(重新验证或重新加载)
一旦资源过期(比如已经超过max-age),在成功向原始服务器验证之前,缓存不能用该资源响应后续请求。
代理会向源服务器再次验证即将返回的响应缓存目前是否仍然有效。
若代理无法联通源服务器就返回504(Gateway Timeout),使用了这条指令上面的max-stale就失效了
11. proxy-revalidate(重新验证或重新加载)
与must-revalidate相似,只适用于共享服务器(如代理),对私有缓存无效
12. no-transform
不得对资源进行转换或转变,Content-Encoding、Content-Range、Content-Type等HTTP头不能由代理修改
可以防止缓存或代理压缩图片
13. cache-extension token
Cache-Control: private, community="UCI"
Cache-Control 首部字段本身没有 community 这个指令。借助 extension tokens 实现了该指令的添加。如果缓存服务器不能理解 community 这个新指令,就会直接忽略。因此,extension tokens 仅对 能理解它的缓存服务器 来说是有意义的。
6.3.2 Connection
Connection 首部字段有以下两个作用:
- 控制不再转发给代理的首部字段
- 管理持久连接
- 控制不再转发给代理的首部字段

在客户端发送请求和服务器返回响应内,使用 Connection 首部字 段,可控制不再转发给代理的首部字段(即 Hop-by-hop首 部)。
- 管理持久连接
Connection: close

HTTP/1.1的默认连接都是持久连接,客户端会在持久连接的基础上连续发送请求,当服务器明确想断开连接的时候,可以指定Connection为close
而1.1之前的版本都是非持久连接,如果想让旧版本维持持久连接就指定为Keep-Alive
6.3.3 Date
声明创建HTTP报文的日期和时间
Date: Tue, 03 Jul 2012 04:40:59 GMT
6.3.4 Pragma
Pragma是HTTP/1.1之前版本的历史遗留字段,用于1.0版向后兼容而定义
属于通用首部字段,但只用在客户端发送的请求中,表示客户端要求所有中间服务器不返回缓存的资源
Cache-Control: no-cachePragma: no-cache
有这个字段是为了兼容所有HTTP版本
6.3.5 Trailer

事先声明报文主体后记录了哪些首部字段,该字段可用于HTTP/1.1分块传输编码时

6.3.6 Transfer-Encoding
规定了用何种传输编码方式

在HTTP/1.1版本里,传输编码方式仅对分块传输编码有效
上图就是通过Transfer-Encoding规定为chunked,来说明使用分块传输编码,分成3312字节和914字节两块
6.3.7 Upgrade
用于检测HTTP协议或者其他协议是否可以使用更高版本进行通信,参数用来指定一个完全不同的通信协议

6.3.8 Via
为了跟踪客户端和服务器之间的传输路径

Via不仅用于追踪报文的转发,还可避免请求回环的发生。 所以必须在经过代理时附加该首部字段内容。
常常和TRACE方法在一起使用。比如代理服务器收到由TRACE方法发送的请求(这时Max-Forwards:0),这个代理服务器就不能再转发该请求了,只会将自身的信息附加到Via首部,返回该请求的响应。
6.3.9 Warning
该首部告知用户一些与缓存相关的问题警告
格式如下L:

并有7种警告:

6.4 请求首部字段
客户端发往服务端所使用的字段,用于补充请求的 附加信息、客户端信息、对响应内容相关的优先级等内容
6.4.1 Accept
通知服务器,用户代理能够处理的媒体类型和优先级

若想要给显示的媒体类型增加优先级,则使用 q= 来额外表示权重值,用分号(;)进行分隔。权重值 q 的范围是 0~1(可精确到小数点 后 3 位),且 1 为最大值。不指定权重 q 值时,默认权重为 q=1.0。
6.4.2 Accept-Charset
通知服务器用户代理支持的字符集和相对优先顺序
6.4.3 Accept-Encoding

Accept-Encoding: gzip, deflate
告知服务器用户代理支持的内容编码以及内容编码的优先级顺序,下面是几个常见的编码格式:
- gzip
由文件压缩程序 gzip(GNU zip)生成的编码格式 (RFC1952),采用 Lempel-Ziv 算法(LZ77)及 32 位循环冗余 校验(Cyclic Redundancy Check,通称 CRC)。
- compress
由 UNIX 文件压缩程序 compress 生成的编码格式,采用 Lempel- Ziv-Welch 算法(LZW)。
- deflate
组合使用 zlib 格式(RFC1950)及由 deflate 压缩算法 (RFC1951)生成的编码格式。
- identity
不执行压缩或不会变化的默认编码格式
6.4.4 Accept-Language

告知服务器用户代理能够处理的自然语言集以及相对优先级,可指定多种自然语言集
6.4.5 Authorization

首部字段Authorization是用来告知服务器用户代理的认证信息
6.4.7 From
首部字段 From 用来告知服务器使用用户代理的用户的电子邮件地址,其使用目的就是为了显示搜索引擎等用户代理的负责人的电子邮件联系方式
6.4.8 Host

多个虚拟主机运行在同一个IP上,必须通过新的字段才能区分不同域名,这个字段就是Host
Host: www.hackr.jp
首部字段 Host 会告知服务器,请求的资源所处的互联网主机名和端口号。Host 首部字段在 HTTP/1.1 规范内是 唯一一个必须被包含在请求内的首部字段。
它存在的意义就是单台服务器分配多个域名的虚拟主机这种工作机制
6.4.9 If-Match

形如If-xxx的请求首部字段,可称为 条件请求,服务器接收到请求后,只有判断条件为真才会执行请求

上图就是当If-Match和ETag值匹配时才会接受请求,否则返回412 Precondition Failed ,也可以使用星号(*)指定If-Match的字段值,这种情况下只要有资源就会处理请求。
6.4.10 If-Modified-Since

它会告诉服务器若 If-Modified-Since字段值早于资源更新的时间,就希望能处理这个请求,如果在字段值时间之后没有更新过,那就不用了,响应304 Not Modified
这个字段用语确认代理或客户端拥有资源的有效性。
6.4.11 If-None-Match

只有在 If-None-Match 的字段值与 ETag 值不一致时,可处理 该请求。与 If-Match 首部字段的作用相反
6.4.12 If-Range

这个字段告知服务器 当If-Range和和请求资源的ETag一致时,则作为范围请求处理,反之返回全部资源。
If-Range其实是If-Match和Range共同使用的一种简化方法,将2次请求减至1次。
6.4.13 If-Unmodified-Since
If-Unmodified-Since: Thu, 03 Jul 2012 00:00:00 GMT
和首部字段 If-Modified-Since 的作用相 反。它的作用的是告知服务器,指定的请求资源只有在字段值内指定 的日期时间之后,未发生更新的情况下,才能处理请求,若发生了更新,则返回412 Precondition Failed作为返回
6.4.14 Max-Forwards

这个字段每转发一次就会减1,当数值变为0时返回响应
使用 HTTP 协议通信时,请求可能会经过代理等多台服务器。途中, 如果代理服务器由于某些原因导致请求转发失败,客户端也就等不到 服务器返回的响应了。对此,我们无从可知。
可以灵活使用首部字段 Max-Forwards,针对以上问题产生的原因展 开调查。由于当 Max-Forwards 字段值为 0 时,服务器就会立即返回 响应,由此我们至少可以对以那台服务器为终点的传输路径的通信状 况有所把握。
6.4.15 Proxy-Authorization
接收到代理服务器发来的认证质询时,客户端会在首部添加Proxy-Authorization,和Authorization差不多,只不过是发生在客户端和代理之间的
6.4.16 Range
Range: bytes=5001-10000
只获取部分资源的返回请求,服务器处理正常会返回206 Partial Content,无法处理则返回200 OK以及全部资源
6.4.17 Referer

首部字段 Referer 会告知服务器请求的原始资源的 URI。
使用这个字段存在安全性的问题,因为可能会把这个referer转发给其他服务器,导致保密信息泄露
6.4.18 TE
首部字段 TE 会告知服务器客户端能够处理响应的传输编码方式及相 对优先级。它和首部字段 Accept-Encoding 的功能很相像,但是用于 传输编码。
6.4.19 User-Agent
用于传达浏览器的种类
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/201001
6.5 响应首部字段
6.5.1 Accept-Ranges

告知客户端服务器能否处理范围请求
- bytes
- none
6.5.2 age

首部字段 Age 能告知客户端,源服务器在多久前创建了响应,字段值的单位为秒。
若创建该响应的服务器是缓存服务器,Age 值是指缓存后的响应再次发起认证到认证完成的时间值。代理创建响应时必须加上首部字段 Age。
6.5.3

告知客户端实体标识,ETag是一种可将资源以字符串的形式唯一表示的方式
当资源更新时,ETag也需要更新
ETag有强、弱之分
- 强ETag值:不论实体发生多细微的变化都会改变值
ETag: "usagi-1234"
- 弱ETag值:只用于提示资源是否相同,只有资源发生了根本改变才会改变ETag值,会在字段值最开始处附加 “W/”
ETag: W/"usagi-1234"
6.5.4 Location

可以将响应接收方引导至某个与请求URI位置不同的资源,配合3XX重定向使用
几乎所有的浏览器在接收到包含首部字段 Location 的响应后,都会强 制性地尝试对已提示的重定向资源的访问。
6.5.5 Proxy-Authenticate
Proxy-Authenticate: Basic realm="Usagidesign Auth"
首部字段 Proxy-Authenticate会把油代理服务器所要求的认证信息发送给客户端,类似于WWW-Authorization
6.5.6 Retry-After

告诉客户端应该在多久之后再次发送请求,配合503 Service Unavailable一块使用,也可以写一个具体的日期时间,也可以写创建响应之后的秒数
6.5.7 Server

告知客户端当前服务器上安装的HTTP服务器的信息,包括版本和安装时的可选项
6.5.8 Vary
它决定了对于未来的一个请求头,应该用一个缓存的回复(response)还是向源服务器请求一个新的回复,它被服务器用来表明在 content negotiation algorithm(内容协商算法)中选择一个资源代表的时候应该使用哪些头部信息(headers).
例如:哪种情况下使用 Vary: User-Agent 头部信息,例如你提供给移动端的内容是不同的,可用防止你客户端误使用了用于桌面端的缓存。 并可帮助Google和其他搜索引擎来发现你的移动端版本的页面,同时告知他们不需要Cloaking。
Vary: User-Agent
6.5.9 WWW-Authenticate
WWW-Authenticate: Basic realm="Usagidesign Auth"
WWW-Authenticate 用于 HTTP 访问认证。它会告知客户端适用于访问请求 URI 所指定资源的认证方案(Basic 或是 Digest)和带参数提示的质询(challenge)。状态码 401 Unauthorized 响应中, 肯定带有首部字段 WWW-Authenticate。
6.6 实体首部字段
实体首部字段处于请求or响应报文的实体部分所使用的首部,用于补充内容的更新时间等信息
6.6.1 Allow

当服务器接收到不支持的 HTTP 方法时,会以状态码 405 Method Not Allowed 作为响应返回。与此同时,还会把所有能支 持的 HTTP 方法写入首部字段 Allow 后返回。
6.6.2 Content-Encoding
告知 c or s 实体的主体部分选用的内容编码方式,内容编码是指不丢失实体信息的前提下所进行的压缩,主要有:
- gzip
- compress
- deflate
- identity
6.6.3 Content-Language
实体使用的自然语言
6.6.4 Content-Length
实体主体部分的大小,单位是字节,担当使用内容编码时不能再使用Content-Length
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

Content-MD5: OGFkZDUwNGVhNGY3N2MxMDIwZmQ4NTBmY2IyTY==
首部字段 Content-MD5 是一串由 MD5 算法生成的值,其目的在于检查报文主体在传输过程中是否保持完整,以及确认传输到达。
对报文主体执行 MD5 算法获得的 128 位二进制数,再通过 Base64 编码后将结果写入 Content-MD5 字段值。由于 HTTP 首部无法记录二进制值,所以要通过Base64 编码处理。为确保报文的有效性,作为接收方的客户端会对报文主体再执行一次相同的 MD5 算法。计算出的值与字段值作比较后,即可判断出报文主体的准确性。
但处在接收阶段的客户 端是无法意识到报文主体以及首部字段 Content-MD5 是已经被篡改过 的。
6.6.7 Content-Range

针对范围请求,返回响应时使用的首部字段 Content-Range,能告知客户端作为响应返回的实体的哪个部分符合范围请求。字段值以字节为 单位,表示当前发送部分及整个实体大小。
6.6.8 Content-Type
说明了实体主体内对象的媒体类型
6.6.9 Expires

首部字段 Expires 会将资源失效的日期告知客户端。
缓存服务器在接收到含有首部字段 Expires 的响应后,会以缓存来应答请求
- 在 Expires 字段值指定的时间之前,响应的副本会一直被保存。
- 当超过指定的时间后,缓存服务器在请求发送过来时,会转向源服务器请求资源。
当首部字段 Cache-Control 有指定 max-age 指令时,比起首部字 段 Expires,会优先处理 max-age 指令。
6.6.10 Last-Modified
指明资源最终修改的时间,一般来说就是Request-URI指定资源修改的时间
6.7 为Cookie服务的首部字段
Cookie的工作机制是用户识别和状态管理
有很多Cookie规格标准文档,下面介绍最广泛使用的,
首部字段:
- Set-Cookie 开始状态管理所使用的Cookie信息 响应首部字段
- Cookie 服务器收到的Cookie 请求首部字段

6.7.1 Set-Cookie
Set-Cookie: status=enable; expires=Tue, 05 Jul 2011 07:26:31 GMT; pat
下面列举Set-Cookie的字段值
| 属性 | 说明 |
|---|---|
| NAME=VALUE | 赋予Cookie的名称和值 |
| expires=DATE | Cookie的有效期(若不明确则默认为浏览器关闭前为止) |
| path=Path | 将服务器上的文件目录作为Cookie的试用对象(不明指则默认为文档所在的文件目录) |
| domain=域名 | 作为Cookie适用对象的域名(不明指则为创建Cookie的服务器的域名) |
| Secure | 仅在HTTPS安全通信时才发送Cookie |
| HttpOnly | 使Cookie不能被JavaScript访问 |
expires 属性
指定浏览器发送Cookie的有效期
一旦Cookie从服务端发送给客户端,服务端就不存在显示删除Cookie的方法,但可以覆盖已过期的Cookie
path 属性
path属性可用于限制指定Cookie的发送范围的文件目录
domain 属性
通过 Cookie 的 domain 属性指定的域名可做到与结尾匹配一致。比 如,当指定 example.com 后,除 example.com 以外,www.example.com 或 www2.example.com 等都可以发送 Cookie。
除非要指定具体的多个域名发送Cookie,不指定domain更安全
secure 属性
用于限制仅在HTTPS安全连接时才可以发送Cookie
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 的信息窃取。
Set-Cookie: name=value; HttpOnly
通过上述设置,通常从 Web 页面内还可以对 Cookie 进行读取操作。 但使用 JavaScript 的 document.cookie 就无法读取附加 HttpOnly 属性后 的 Cookie 的内容了。因此,也就无法在 XSS 中利用 JavaScript 劫持 Cookie 了。
6.7.2 Cookie
当客户端想获得 HTTP 状态管理支持时,就会在请求中包含从服务器接收到的 Cookie。接收到多个 Cookie 时,同样可以以多个 Cookie 形式发送。
6.8 其他首部字段
http首部字段是可以自行扩展的
6.8.1 X-Frame-Options
X-Frame-Options: DENY
用于控制网站内容在其他 Web 网站的 Frame 标签内的显示问题。其主要目的是为了防 止点击劫持(clickjacking)攻击。
有两个可指定的字段值:
- DENY:拒绝
- SAMEORIGIN :仅同源域名下的页面(Top-level-browsing- context)匹配时许可。(比如,当指定 http://hackr.jp/sample.html 页面为 SAMEORIGIN 时,那么 hackr.jp 上所有页面的 frame 都被 允许可加载该页面,而 example.com 等其他域名的页面就不行了)
6.8.2 X-XSS-Protection
这个首部字段针对跨站脚本XSS的一种对策,用于控制浏览器XSS防护机制的开关
可设置为:
- 0:将XSS过滤设置为无效状态
- 1:将XSS过滤设置为有效状态
6.8.3 DNT

首部字段 DNT 属于 HTTP 请求首部,其中 DNT 是 Do Not Track 的简 称,意为拒绝个人信息被收集,是表示拒绝被精准广告追踪的一种方 法。
首部字段 DNT 可指定的字段值如下。
- 0 :同意被追踪
- 1 :拒绝被追踪
6.8.4 P3P
P3P: CP="CAO DSP LAW CURa ADMa DEVa TAIa PSAa PSDa IVAa IVDa OUR BUS
首部字段 P3P 属于 HTTP 相应首部,通过利用 P3P(The Platform for Privacy Preferences,在线隐私偏好平台)技术,可以让 Web 网站上 的个人隐私变成一种仅供程序可理解的形式,以达到保护用户隐私的目的。
步骤如下:
步骤 1:创建 P3P 隐私
步骤 2:创建 P3P 隐私对照文件后,保存命名在 /w3c/p3p.xml
步骤 3:从 P3P 隐私中新建 Compact policies 后,输出到 HTTP 响应中
