互联网工程任务组 (IETF) P. Meenan, Editor
请求评议：9842 Google LLC
类别：标准轨道 Y. Weiss, Editor
ISSN: 2070-1721 Shopify Inc.
September 2025

压缩字典传输

摘要

本文件规范了在超文本传输协议（HTTP）中使用基于字典的压缩机制。通过利用该技术，客户端和服务器可以减少传输数据的大小，从而改善性能并降低带宽消耗。本文扩展了现有的 HTTP 压缩方法，并为在 HTTP 协议内交付与使用压缩字典提供了指导。

本备忘录的状态

这是一个互联网标准轨道文档。

本文件是互联网工程任务组（IETF）的成果，代表 IETF 社区的共识。它已获得公开评审，并由互联网工程指导小组（IESG）批准发布。有关互联网标准的更多信息，请参阅 RFC 7841 第2节.

有关本文档当前状态、任何勘误以及如何提供反馈的信息，可在 https://www.rfc-editor.org/info/rfc9842 获取。

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

1. 引言

本规范定义了一种机制，允许将指定的 HTTP [HTTP] 响应用作未来支持外部字典的压缩方案（例如 Brotli [RFC7932] 和 Zstandard [ZSTD]） 的外部字典。

本文描述了用于协商字典使用的 HTTP 首部，并为使用协商字典压缩的 Brotli 和 Zstandard 注册了 content-encoding 值。

字典使用的协商利用了 HTTP 的内容协商机制（参见 [HTTP] 第 12 节），并可与所有 HTTP 版本一起使用。

1.1. 用例

任何 HTTP 响应都可以被指定用于作为未来请求的压缩字典，这提供了很大的灵活性。下面描述了两个常见且经常出现的用例。

1.1.1. 版本升级

将资源的先前版本用作新版本的字典，可以传送基于差异的压缩变更（delta-compressed），通常比仅使用压缩本身能获得更小的响应。

例如：

客户端 服务器 GET /app.v1.js 200 OK Use-As-Dictionary: match="/app*js" <full app.v1.js 资源 - 100KB 已压缩> 一段 时间 之后 ... 客户端 服务器 GET /app.v2.js Available-Dictionary: :pZGm1A...2a2fFG4=: Accept-Encoding: gzip, br, zstd, dcb, dcz 200 OK Content-Encoding: dcb <基于差异压缩的 app.v2.js 资源 - 1KB>

图 1：版本升级示例

1.1.2. 通用内容

如果多个资源在其响应中共享通用模式，则引用一个包含这些通用模式的外部字典会很有用，这能将这些通用模式有效地从响应中压缩出去。示例包括站点上类似页面的通用模板 HTML，以及 API 调用中常见的键和值。

例如：

客户端 服务器 GET /index.html 200 OK Link: <.../dict>; rel="compression-dictionary" <full index.html 资源 - 100KB 已压缩> GET /dict 200 OK Use-As-Dictionary: match="/*html" 一段 时间 之后 ... 客户端 服务器 GET /page2.html Available-Dictionary: :pZGm1A...2a2fFG4=: Accept-Encoding: gzip, br, zstd, dcb, dcz 200 OK Content-Encoding: dcb <基于差异压缩的 page2.html 资源 - 10KB>

图 2：通用内容示例

1.2. 符号约定

本文档中关键词 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY" 和 "OPTIONAL" 在仅当它们全部为大写时，应按 BCP 14（[RFC2119]）和 [RFC8174] 的定义来解释。

本文使用来自 RFC 9651 第 3 节 的术语来指定语法与解析：Dictionary、String、Inner List、Token 和 Byte Sequence。

本文使用在 [FOLDING] 中描述的行折叠策略。

本文还使用来自 [HTTP] 和 [HTTP-CACHING] 的术语。

2. 字典协商

2.1. Use-As-Dictionary

当服务器响应 HTTP 请求时，可以声明该响应可被用作未来对匹配指定规则的 URL 的字典，规则通过 "Use-As-Dictionary" 响应首部来指定。

"Use-As-Dictionary" 响应首部是一个 Structured Field（[STRUCTURED-FIELDS]）中的 Dictionary，包含 "match"、"match-dest"、"id" 和 "type" 的值。

2.1.1. "match"

"Use-As-Dictionary" 响应首部中的 "match" 值为一个 String，提供用于请求匹配的 URL 模式（参见 [URLPATTERN]）。

用于匹配的 URL 模式不支持正则表达式。

下面给出用于验证某个 String 值是否为不使用正则且与字典同源的有效 URL 模式的算法（参见 [HTTP] 第 4.3.1 节）。对于有效的 match 模式该算法返回 TRUE；对于无效的模式返回 FALSE（该模式 MUST NOT 被使用）。

  1. 设 MATCH 为给定字典的 "match" 值。

  2. 设 URL 为该字典请求的 URL。

  3. 设 PATTERN 为通过执行“创建 URL pattern”步骤并设置 input=MATCH、baseURL=URL（参见 URL Pattern 标准 第 1.4 节）而创建的 "URL pattern struct"。

  4. 如果对 PATTERN 运行“has regexp groups”步骤的结果为 TRUE，则返回 FALSE（参见 第 1.4 节 的最后一项列表）。

  5. 返回 TRUE。

"match" 值是必需的，字典要被认为有效，"Use-As-Dictionary" 首部中 MUST 包含该值。

在 HTTP 层面上，指定的匹配模式将对 URL 路径的百分号编码版本进行匹配（参见 [URL] 第 2 节）。

例如，URL "http://www.example.com/düsseldorf" 会被编码为 "http://www.example.com/d%C3%BCsseldorf"，相应的匹配模式可以是：

Use-As-Dictionary: match="/d%C3%BCsseldorf"

2.1.2. "match-dest"

"Use-As-Dictionary" 响应首部中的 "match-dest" 值是一个 Inner List 的 String 值，提供了字典可以匹配的 Fetch 请求目的地列表（参见 Fetch 标准 第 5.4 节 中的 "RequestDestination"）。

"match-dest" 的空列表 MUST 匹配所有目的地。

对于不支持请求目的地的客户端，客户端 MUST 将其视为空列表并匹配所有目的地。

"match-dest" 值是可选的，默认为空列表。

2.1.3. "id"

"Use-As-Dictionary" 响应首部中的 "id" 值是一个 String，指定服务器为该字典提供的标识符。如果存在且长度大于零，则当客户端为相同字典发送 "Available-Dictionary" 请求首部时，客户端 MUST 在请求中将该值发送回服务器，使用 "Dictionary-ID" 请求首部（参见第 2.2 节）。

客户端应将服务器标识符视为不透明字符串。

服务器不应依赖该标识符来保证字典内容。必须在使用前验证字典哈希。

"id" 值字符串的长度（解码后）支持最多 1024 个字符。

"id" 值是可选的，默认值为空字符串。

2.1.4. "type"

"Use-As-Dictionary" 响应首部中的 "type" 值是一个 Token，描述所提供字典的文件格式。

“raw” 被定义为表示未格式化字节块的字典格式，适用于任何压缩方案。

如果客户端收到的字典类型是其不理解的，客户端 MUST NOT 使用该字典。

"type" 值是可选的，默认为 "raw"。

2.1.5. 示例

2.1.5.1. 路径前缀

如下所示的响应首部会指定匹配与原始请求同源且路径前缀为 /product/ 的任何文档请求：

NOTE: '\' line wrapping per RFC 8792

Use-As-Dictionary: \
  match="/product/*", match-dest=("document")
2.1.5.2. 版本目录

如下所示的响应首部会匹配以 "/app/" 开头并以 "/main.js" 结尾的任何路径：

Use-As-Dictionary: match="/app/*/main.js"

2.2. Available-Dictionary

当 HTTP 客户端为某个请求拥有合适的字典时，它可以在请求中添加 "Available-Dictionary" 请求首部，告知服务器它有可用的字典用于压缩。

"Available-Dictionary" 请求首部是一个 Structured Field（[STRUCTURED-FIELDS]）中的 Byte Sequence，包含用于单个可用字典内容的 SHA-256 哈希值（参见 [SHA-256]）。

客户端 MUST 只发送一个 "Available-Dictionary" 请求首部，且只包含它可用的最佳匹配的单个哈希值。

例如：

Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:

2.2.1. 字典新鲜度要求

要被视为匹配，字典资源 MUST 要么是新鲜的（参见 [HTTP-CACHING]），要么被允许作为过期内容提供（参见 [RFC5861]）。

2.2.2. 字典 URL 匹配

当因 "Use-As-Dictionary" 指令而存储字典时，它包含一个 "match" 字符串和一个可选的 "match-dest" 字符串，这些将用于将客户端的外发请求与可用字典进行匹配。

要判断外发请求是否与某个字典匹配，下面的算法在匹配成功时返回 TRUE，否则返回 FALSE：

  1. 如果当前客户端支持请求目的地并且字典提供了 "match-dest" 字符串：

    • 设 DEST 为该字典的 "match-dest" 值。

    • 设 REQUEST_DEST 为当前请求的 destination 值。

    • 如果 DEST 不是空列表且 REQUEST_DEST 不在 DEST 列表中，则返回 FALSE。

  2. 设 BASEURL 为该字典请求的 URL。

  3. 设 URL 为正在检查的外发请求的 URL。

  4. 如果 BASEURL 的 Origin 与 URL 的 Origin 不相同，则返回 FALSE（参见 [HTTP] 第 4.3.1 节）。

  5. 设 MATCH 为给定字典的 "match" 值。

  6. 设 PATTERN 为通过运行“创建 URL pattern”步骤并设置 input=MATCH、baseURL=URL 而创建的 "URL pattern struct"（参见 URL Pattern 标准 第 1.4 节）。

  7. 返回对 PATTERN 运行 "match" 步骤（input=URL）的结果，该步骤会检查请求 URL 与所提供的 "match" 字符串是否匹配（参见 第 1.4 节）。

2.2.3. 多个匹配字典

当有多个字典匹配给定请求 URL 时，客户端 MUST 使用以下规则选取单个字典：

  1. 对于支持请求目的地的客户端，指定并匹配 "match-dest" 的字典优先于未使用目的地的匹配。

  2. 在目的地优先级等价时，具有最长 "match" 的字典优先。

  3. 在目的地和匹配长度都等价时，最近获取到的字典优先。

2.3. Dictionary-ID

当 HTTP 客户端为某个请求拥有合适的字典并且该字典在 "Use-As-Dictionary" 响应首部中携带由服务器提供的 "id" 时，客户端 MUST 在请求中回显该存储的 "id"，使用 "Dictionary-ID" 请求首部。

"Dictionary-ID" 请求首部是一个 Structured Field（[STRUCTURED-FIELDS]）中的 String，最长为 1024 个字符（解码后），并且 MUST 与服务器提供的 "id" 完全相同。

例如，假设某个 HTTP 响应设置了字典 ID：

Use-As-Dictionary: match="/app/*/main.js", id="dictionary-12345"

未来匹配该字典的请求将同时包含哈希和 ID：

Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:
Dictionary-ID: "dictionary-12345"

4. 字典压缩的 Brotli

"dcb" 内容编码标识资源为 “Dictionary-Compressed Brotli” 流。

“Dictionary-Compressed Brotli” 流具有一个固定头，后面跟一个 Shared Brotli [SHARED-BROTLI] 流。头部由 4 字节的固定序列和所使用外部字典的 32 字节哈希组成。Shared Brotli 流是使用引用的外部字典并且压缩窗口最大为 16 MB 创建的。

"dcb" 内容编码使用的字典为第 2.1.4 节 中定义的 "raw" 字典类型，并按 [SHARED-BROTLI] 第 8.2 节 将其视为前缀字典。

36 字节的固定头如下：

Magic_Number:
4 个固定字节 -- 0xff, 0x44, 0x43, 0x42。
SHA_256_Hash:
32 字节。字典的 SHA-256 哈希摘要（参见 [SHA-256]）。

声明支持 dcb 内容编码的客户端 MUST 能够解压使用窗口大小最多为 16 MB 压缩的资源。

对于 Brotli 压缩，完整字典在压缩和解压缩期间均可用且不受压缩窗口限制，这允许对大于压缩窗口的资源进行差异压缩。

5. 字典压缩的 Zstandard

"dcz" 内容编码标识资源为 “Dictionary-Compressed Zstandard” 流。

“Dictionary-Compressed Zstandard” 流是一个二进制流，起始为 40 字节的固定头，随后是使用外部字典压缩的 Zstandard [ZSTD] 流。

"dcz" 内容编码使用的字典为第 2.1.4 节 中定义的 "raw" 字典类型，并按 [ZSTD] 第 5 节 将其视为原始字典。

40 字节头由 8 字节的固定序列后跟外部字典的 32 字节 SHA-256 哈希组成：

Magic_Number:
8 个固定字节 -- 0x5e, 0x2a, 0x4d, 0x18, 0x20, 0x00, 0x00, 0x00。
SHA_256_Hash:
32 字节。字典的 SHA-256 哈希摘要（参见 [SHA-256]）。

该 40 字节头是一个 Zstandard 的 skippable frame（小端 0x184D2A5E），长度字段为 32 字节（小端 0x00000020），与现有 Zstandard 解码器兼容。

声明支持 dcz 内容编码的客户端 MUST 能够解压使用窗口大小至少为 8 MB 或字典大小的 1.25 倍（取二者较大者），上限为 128 MB 的资源。

所使用的窗口大小会被编码在内容中（当前只能以 2 的幂表示），并且 MUST 小于上述限制。实现 MAY 将超出限制的窗口大小视为解码错误。

对于 Zstandard 压缩，完整字典在压缩和解压缩过程中可用，直到输入大小超过压缩窗口为止。超过该点后，字典将变得不可用。使用比字典大 1.25 倍的压缩窗口允许对在版本之间增长 25% 的资源进行完整的差异压缩，同时仍让客户端控制为给定响应需要分配的内存。

6. 协商内容编码

当某个压缩字典可用于压缩响应时，所使用的编码通过 HTTP 中常规的内容编码协商机制进行协商，即使用请求首部 "Accept-Encoding" 和响应首部 "Content-Encoding"。

将使用的字典单独协商，并在请求首部 "Available-Dictionary" 中进行通告。

6.1. Accept-Encoding

当某个请求可用字典存在且客户端选择在该请求上启用基于字典的内容编码时，客户端将其支持的字典感知内容编码添加到 "Accept-Encoding" 请求首部。例如：

Accept-Encoding: gzip, deflate, br, zstd, dcb, dcz

当客户端没有匹配请求的已存字典或选择不在该请求上使用字典时，客户端 MUST NOT 在 "Accept-Encoding" 请求首部中发送其字典感知内容编码。

6.2. Content-Encoding

如果服务器支持客户端通告的某个字典编码并选择使用客户端通告的字典对响应的内容进行压缩，则服务器将 "Content-Encoding" 响应首部设置为所选算法的相应值。例如： 

Content-Encoding: dcb

如果响应可被缓存，则 MUST 包含 "Vary" 首部，以防止缓存将字典压缩的资源提供给不支持它们的客户端，或将使用错误字典压缩的响应提供给客户端。例如：

Vary: accept-encoding, available-dictionary

7. IANA 注意事项

7.1. 内容编码注册

IANA 已向其维护的 “HTTP Content Coding Registry” 添加以下条目（位于 <https://www.iana.org/assignments/http-parameters/>）：

Name:
dcb
Description:
“Dictionary-Compressed Brotli” 数据格式。
Reference:
RFC 9842, 第 4 节
Name:
dcz
Description:
“Dictionary-Compressed Zstandard” 数据格式。
Reference:
RFC 9842, 第 5 节

7.2. 首部字段注册

IANA 已向其维护的 “Hypertext Transfer Protocol (HTTP) Field Name Registry” 添加以下条目（位于 <https://www.iana.org/assignments/http-fields/>）：

Table 1
Field Name Status Reference
Use-As-Dictionary permanent RFC 9842, 第 2.1 节
Available-Dictionary permanent RFC 9842, 第 2.2 节
Dictionary-ID permanent RFC 9842, 第 2.3 节

8. 兼容性注意事项

网络路径上常见存在截取、检查和处理 HTTP 请求的设备（如 Web 代理、防火墙、入侵检测系统等）。为尽量减少这些设备错误处理字典压缩响应的风险，压缩字典传输 MUST 仅在安全上下文（HTTPS）中使用。

9. 安全性注意事项

Brotli（[RFC7932]）、Shared Brotli（[SHARED-BROTLI]）和 Zstandard（[ZSTD]）的安全注意事项同样适用于各自算法的基于字典的版本。

9.1. 内容更改

字典必须与内容采用相同的安全预防措施对待，因为对字典的更改会导致解压后内容发生变化。

使用字典内容的 SHA-256 哈希对字典进行验证，以确保客户端和服务器使用相同的字典。由于字典与内容来自同一源，SHA-256 的强度并不是专门为了抵抗攻击而必须的。如果未来发现 SHA-256 有弱点并决定使用不同的哈希算法进行字典协商，则可以通过扩展 "Use-As-Dictionary" 首部以指定不同算法，服务器将忽略不使用更新哈希的 "Available-Dictionary" 请求。

9.2. 读取内容

在 RFC 7457 第 2.6 节 中讨论的压缩攻击表明，将来自混合来源（例如公共与私人）的数据压缩在一起是危险的。数据源不仅包括被压缩的数据，还包括字典。例如，如果使用仅包含公共数据的字典来压缩包含机密 cookie 的数据，关于这些 cookie 的信息仍会泄露。

字典可以暴露有关被压缩数据的信息，反之亦然。也就是说，当对手能够控制被压缩数据的某些部分并观察压缩后的大小时，被字典压缩的数据可能泄露字典内容；另一方面，如果对手能控制字典，对手可以从压缩数据中推断出被压缩数据的信息。

9.3. 安全缓解

如果任何缓解措施不通过，客户端 MUST 丢弃该响应并返回错误。

9.3.1. 跨源保护

为确保字典只能影响与字典提供源相同源的内容，用于将字典匹配到请求的 URL Pattern（参见 第 2.1.1 节）保证与提供字典的来源相同。

9.3.2. 响应可读性

对于像浏览器这类为响应有效负载的可读性和用户跟踪提供额外保护的客户端，必须采取额外保护措施以确保字典压缩不会泄露原本不可得的信息。

在这些情况下，仅当字典和压缩响应对客户端完全可读时，才 MUST 使用字典压缩。

以浏览器术语，这意味着要么字典和压缩响应与其被获取的上下文同源，要么响应为跨源且通过了跨源资源共享（CORS）检查（参见 Fetch 标准 第 4.9 节）。

9.3.3. 服务器责任

如同在安全上下文中使用任何压缩内容一样，如果攻击者能控制字典的任何部分或能读取字典并控制被压缩内容的任何部分，同时通过多次请求变更字典或注入内容来观察响应大小或处理时间，则可能发生计时攻击。在这种攻击下，响应大小或处理时间的变化会泄露关于内容的信息，从而可能读取本应安全的响应。

一般而言，服务器可以通过防止每次请求的变化（例如阻止为相同内容主动使用多个字典）、在任何内容来自不受控来源时禁用压缩、以及对字典内容采取与响应内容相同的安全保护来减轻此类攻击。此外，以下对服务器的要求旨在当客户端提供表明跨源请求上下文的 CORS 请求首部字段时禁用字典感知压缩。

下面的算法对于那些应考虑不使用字典压缩的跨源请求返回 FALSE：

  1. 如果不存在 "Sec-Fetch-Site" 请求首部，则返回 TRUE。

  2. 如果 "Sec-Fetch-Site" 请求首部的值为 "same-origin"，则返回 TRUE。

  3. 如果不存在 "Sec-Fetch-Mode" 请求首部，则返回 TRUE。

  4. 如果 "Sec-Fetch-Mode" 请求首部的值为 "navigate" 或 "same-origin"，则返回 TRUE。

  5. 如果 "Sec-Fetch-Mode" 请求首部的值为 "cors"：

    • 如果响应不包含 "Access-Control-Allow-Origin" 响应首部，则返回 FALSE。

    • 如果请求不包含 "Origin" 请求首部，则返回 FALSE。

    • 如果 "Access-Control-Allow-Origin" 响应首部的值为 "*"，则返回 TRUE。

    • 如果 "Access-Control-Allow-Origin" 响应首部的值与 "Origin" 请求首部的值匹配，则返回 TRUE。

  6. 返回 FALSE。

10. 隐私注意事项

由于字典在未来请求中通过字典内容的哈希进行通告，因此可能被滥用为追踪 cookie。

为缓解任何额外的跟踪问题，客户端 MUST 以与处理 cookie 相同的方式对待字典（参见 [RFC6265]）。这包括使用与 cookie 相同或更严格的分区存储策略，并在清除 cookie 时清除字典。

11. 参考文献

11.1. 规范性参考文献

[FETCH]
WHATWG，“Fetch Standard”，WHATWG 活动标准，<https://fetch.spec.whatwg.org/>。
Commit snapshot: <https://fetch.spec.whatwg.org/commit-snapshots/5a9680638ebfc2b3b7f4efb2bef0b579a2663951/>。
[FOLDING]
Watsen, K., Auerswald, E., Farrel, A., 和 Q. Wu，“Handling Long Lines in Content of Internet-Drafts and RFCs”，RFC 8792，2020 年 6 月，<https://www.rfc-editor.org/info/rfc8792>。
[HTTP-CACHING]
Fielding, R., Ed., Nottingham, M., Ed., 和 J. Reschke, Ed., “HTTP Caching”，STD 98，RFC 9111，2022 年 6 月，<https://www.rfc-editor.org/info/rfc9111>。
[HTTP]
Fielding, R., Ed., Nottingham, M., Ed., 和 J. Reschke, Ed., “HTTP Semantics”，STD 97，RFC 9110，2022 年 6 月，<https://www.rfc-editor.org/info/rfc9110>。
[RFC2119]
Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”，BCP 14，RFC 2119，1997 年 3 月，<https://www.rfc-editor.org/info/rfc2119>。
[RFC8174]
Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”，BCP 14，RFC 8174，2017 年 5 月，<https://www.rfc-editor.org/info/rfc8174>。
[SHA-256]
Eastlake 3rd, D. 和 T. Hansen，“US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)”，RFC 6234，2011 年 5 月，<https://www.rfc-editor.org/info/rfc6234>。
[SHARED-BROTLI]
Alakuijala, J., Duong, T., Kliuchnikov, E., Szabadka, Z., 和 L. Vandevenne, Ed., “Shared Brotli Compressed Data Format”，RFC 9841，2025 年 9 月，<https://www.rfc-editor.org/info/rfc9841>。
[STRUCTURED-FIELDS]
Nottingham, M. 和 P-H. Kamp，“Structured Field Values for HTTP”，RFC 9651，2024 年 9 月，<https://www.rfc-editor.org/info/rfc9651>。
[URLPATTERN]
WHATWG，“URL Pattern Standard”，WHATWG 活动标准，<https://urlpattern.spec.whatwg.org/>。
Commit snapshot: <https://urlpattern.spec.whatwg.org/commit-snapshots/696b4029d52e5854044bac6b72cdb198cb962ed0/>。
[URL]
Berners-Lee, T., Fielding, R., 和 L. Masinter，“Uniform Resource Identifier (URI): Generic Syntax”，STD 66，RFC 3986，2005 年 1 月，<https://www.rfc-editor.org/info/rfc3986>。
[WEB-LINKING]
Nottingham, M., “Web Linking”，RFC 8288，2017 年 10 月，<https://www.rfc-editor.org/info/rfc8288>。
[ZSTD]
Collet, Y. 和 M. Kucherawy, Ed., “Zstandard Compression and the 'application/zstd' Media Type”，RFC 8878，2021 年 2 月，<https://www.rfc-editor.org/info/rfc8878>。

11.2. 补充性参考文献

[RFC5861]
Nottingham, M., “HTTP Cache-Control Extensions for Stale Content”，RFC 5861，2010 年 5 月，<https://www.rfc-editor.org/info/rfc5861>。
[RFC6265]
Barth, A., “HTTP State Management Mechanism”，RFC 6265，2011 年 4 月，<https://www.rfc-editor.org/info/rfc6265>。
[RFC7457]
Sheffer, Y., Holz, R., 和 P. Saint-Andre，“Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)”，RFC 7457，2015 年 2 月，<https://www.rfc-editor.org/info/rfc7457>。
[RFC7932]
Alakuijala, J. 和 Z. Szabadka，“Brotli Compressed Data Format”，RFC 7932，2016 年 7 月，<https://www.rfc-editor.org/info/rfc7932>。

作者地址

Patrick Meenan (editor)
Google LLC
EMail: pmeenan@google.com
Yoav Weiss (editor)
Shopify Inc.
EMail: yoav.weiss@shopify.com