跳到主要内容

5. 头字段定义 (Header Field Definitions)

本节定义与缓存相关的 HTTP/1.1 头字段的语法和语义。

5.1. Age​

"Age" 头字段传达发送方对自源服务器生成或成功验证响应以来的时间量的估计。Age 值按第 4.2.3 节中指定的方式计算。

Age = delta-seconds

Age 字段值是非负整数，表示以秒为单位的时间（参见第 1.2.1 节）。

Age 头字段的存在意味着响应不是由源服务器为此请求生成或验证的。但是，缺少 Age 头字段并不意味着联系了源服务器，因为响应可能是从不实现 Age 的 HTTP/1.0 缓存接收的。

5.2. Cache-Control​

"Cache-Control" 头字段用于为请求/响应链上的缓存指定指令。此类缓存指令是单向的，即请求中存在指令并不意味着响应中也要给出相同的指令。

缓存必须遵守本节中定义的 Cache-Control 指令的要求。有关如何处理在其他地方定义的 Cache-Control 指令的信息，请参见第 5.2.3 节。

注意： 某些 HTTP/1.0 缓存可能不实现 Cache-Control。

代理，无论是否实现缓存，都必须在转发的消息中传递缓存指令，无论这些指令对该应用程序的重要性如何，因为这些指令可能适用于请求/响应链上的所有接收方。不可能将指令定向到特定缓存。

缓存指令由标记标识，不区分大小写进行比较，并具有可选参数，该参数可以使用标记和引用字符串语法。对于下面定义的定义参数的指令，接收方应该接受两种形式，即使记录了首选其中一种。对于本规范未定义的任何指令，接收方必须接受两种形式。

Cache-Control   = 1#cache-directive

cache-directive = token [ "=" ( token / quoted-string ) ]

对于下面定义的缓存指令，除非另有说明，否则不定义（也不允许）参数。

5.2.1. 请求 Cache-Control 指令 (Request Cache-Control Directives)​

5.2.1.1. max-age​

参数语法：

delta-seconds (see Section 1.2.1)

"max-age" 请求指令表示客户端不愿意接受年龄大于指定秒数的响应。除非还存在 max-stale 请求指令，否则客户端不愿意接受过期响应。

此指令使用参数语法的标记形式：例如，'max-age=5' 而不是 'max-age="5"'。发送方不应该生成引用字符串形式。

5.2.1.2. max-stale​

参数语法：

delta-seconds (see Section 1.2.1)

"max-stale" 请求指令表示客户端愿意接受已超过其新鲜度生命周期的响应。如果为 max-stale 分配了值，则客户端愿意接受超过其新鲜度生命周期不超过指定秒数的响应。如果未为 max-stale 分配值，则客户端愿意接受任何年龄的过期响应。

此指令使用参数语法的标记形式：例如，'max-stale=10' 而不是 'max-stale="10"'。发送方不应该生成引用字符串形式。

5.2.1.3. min-fresh​

参数语法：

delta-seconds (see Section 1.2.1)

"min-fresh" 请求指令表示客户端愿意接受其新鲜度生命周期不小于其当前年龄加上指定秒数的响应。也就是说，客户端想要一个至少在指定秒数内仍然新鲜的响应。

此指令使用参数语法的标记形式：例如，'min-fresh=20' 而不是 'min-fresh="20"'。发送方不应该生成引用字符串形式。

5.2.1.4. no-cache​

"no-cache" 请求指令表示缓存不得在源服务器上成功验证的情况下使用存储的响应来满足请求。

5.2.1.5. no-store​

"no-store" 请求指令表示缓存不得存储此请求或对其的任何响应的任何部分。此指令适用于私有缓存和共享缓存。在此上下文中，"不得存储"意味着缓存不得有意将信息存储在非易失性存储中，并且必须尽最大努力在转发后不做延迟地从易失性存储中删除信息。

此指令不是确保隐私的可靠或充分机制。特别是，恶意或受损的缓存可能不识别或遵守此指令，并且通信网络可能容易受到窃听。

请注意，如果从缓存中满足包含此指令的请求，则 no-store 请求指令不适用于已存储的响应。

5.2.1.6. no-transform​

"no-transform" 请求指令表示中介（无论是否实现缓存）不得转换有效负载，如 [RFC7230] 的第 5.7.2 节中所定义。

5.2.1.7. only-if-cached​

"only-if-cached" 请求指令表示客户端仅希望获取存储的响应。如果缓存接收到此指令，则应该使用与请求的其他约束一致的存储响应进行响应，或使用 504（Gateway Timeout）状态码进行响应。如果一组缓存作为具有良好内部连接的统一系统运行，则成员缓存可以在该组缓存内转发此类请求。

5.2.2. 响应 Cache-Control 指令 (Response Cache-Control Directives)​

5.2.2.1. must-revalidate​

"must-revalidate" 响应指令表示一旦响应变得过期，缓存不得在源服务器上成功验证的情况下使用该响应来满足后续请求。

must-revalidate 指令对于支持某些协议功能的可靠操作是必要的。在所有情况下，缓存都必须遵守 must-revalidate 指令；特别是，如果缓存由于任何原因无法到达源服务器，它必须生成 504（Gateway Timeout）响应。

当且仅当未能验证表示上的请求可能导致不正确的操作（例如静默未执行的金融交易）时，服务器才应该使用 must-revalidate 指令。

5.2.2.2. no-cache​

参数语法：

#field-name

"no-cache" 响应指令表示响应不得在源服务器上成功验证的情况下用于满足后续请求。这允许源服务器防止缓存在不联系它的情况下使用它来满足请求，即使是已配置为发送过期响应的缓存。

如果 no-cache 响应指令指定一个或多个字段名称，则缓存可以使用响应来满足后续请求，但须遵守对缓存的任何其他限制。但是，响应中具有列出的字段名称的任何头字段不得在对后续请求的响应中发送，除非与源服务器成功重新验证。这允许源服务器防止响应中某些头字段的重用，同时仍允许缓存响应的其余部分。

给定的字段名称不限于本规范定义的头字段集。字段名称不区分大小写。

此指令使用参数语法的引用字符串形式。发送方不应该生成标记形式（即使对于单条目列表似乎不需要引用）。

注意： 尽管已向后移植到许多实现，但某些 HTTP/1.0 缓存不会识别或遵守此指令。此外，带有字段名称的 no-cache 响应指令通常被缓存处理为接收到不合格的 no-cache 指令；即，未广泛实现对合格形式的特殊处理。

5.2.2.3. no-store​

"no-store" 响应指令表示缓存不得存储立即请求或响应的任何部分。此指令适用于私有缓存和共享缓存。在此上下文中，"不得存储"意味着缓存不得有意将信息存储在非易失性存储中，并且必须尽最大努力在转发后尽快从易失性存储中删除信息。

此指令不是确保隐私的可靠或充分机制。特别是，恶意或受损的缓存可能不识别或遵守此指令，并且通信网络可能容易受到窃听。

5.2.2.4. no-transform​

"no-transform" 响应指令表示中介（无论是否实现缓存）不得转换有效负载，如 [RFC7230] 的第 5.7.2 节中所定义。

5.2.2.5. public​

"public" 响应指令表示任何缓存都可以存储响应，即使响应通常是不可缓存的或仅在私有缓存中可缓存。（有关响应包含 Authorization 的请求时使用 public 的其他详细信息，请参见第 3.2 节，有关 public 如何影响通常不会存储的响应（由于其状态码默认未定义为可缓存）的详细信息，请参见第 3 节；参见第 4.2.2 节。）

5.2.2.6. private​

参数语法：

#field-name

"private" 响应指令表示响应消息旨在供单个用户使用，并且不得由共享缓存存储。私有缓存可以存储响应并将其重用于以后的请求，即使响应通常是不可缓存的。

如果 private 响应指令指定一个或多个字段名称，则此要求仅限于与列出的响应头字段关联的字段值。也就是说，共享缓存不得存储指定的字段名称，而可以存储响应消息的其余部分。

给定的字段名称不限于本规范定义的头字段集。字段名称不区分大小写。

此指令使用参数语法的引用字符串形式。发送方不应该生成标记形式（即使对于单条目列表似乎不需要引用）。

注意： "private" 一词的这种用法仅控制响应可以存储的位置；它不能确保消息内容的隐私。此外，带有字段名称的 private 响应指令通常被缓存处理为接收到不合格的 private 指令；即，未广泛实现对合格形式的特殊处理。

5.2.2.7. proxy-revalidate​

"proxy-revalidate" 响应指令与 must-revalidate 响应指令具有相同的含义，只是它不适用于私有缓存。

5.2.2.8. max-age​

参数语法：

delta-seconds (see Section 1.2.1)

"max-age" 响应指令表示在其年龄大于指定秒数后，响应将被视为过期。

此指令使用参数语法的标记形式：例如，'max-age=5' 而不是 'max-age="5"'。发送方不应该生成引用字符串形式。

5.2.2.9. s-maxage​

参数语法：

delta-seconds (see Section 1.2.1)

"s-maxage" 响应指令表示，在共享缓存中，此指令指定的最大年龄覆盖 max-age 指令或 Expires 头字段指定的最大年龄。s-maxage 指令还暗示 proxy-revalidate 响应指令的语义。

此指令使用参数语法的标记形式：例如，'s-maxage=10' 而不是 's-maxage="10"'。发送方不应该生成引用字符串形式。

5.2.3. 缓存控制扩展 (Cache Control Extensions)​

Cache-Control 头字段可以通过使用一个或多个缓存扩展标记来扩展，每个标记都有一个可选值。缓存必须忽略无法识别的缓存指令。

信息性扩展（不需要更改缓存行为的扩展）可以在不更改其他指令的语义的情况下添加。

行为扩展旨在通过充当现有缓存指令基础的修饰符来工作。提供新指令和旧指令，以便不理解新指令的应用程序将默认为旧指令指定的行为，而理解新指令的应用程序将识别它为修改与旧指令关联的要求。通过这种方式，可以在不破坏已部署缓存的情况下对现有缓存控制指令进行扩展。

例如，考虑一个名为 "community" 的假设新响应指令，它充当 private 指令的修饰符：除了私有缓存之外，仅由命名社区成员共享的任何缓存都允许缓存响应。希望允许 UCI 社区在其共享缓存中使用原本私有的响应的源服务器可以通过包含以下内容来实现：

Cache-Control: private, community="UCI"

识别此类社区缓存扩展的缓存可以根据该扩展扩大其行为。不识别社区缓存扩展的缓存将忽略它并遵守 private 指令。

5.3. Expires​

"Expires" 头字段给出响应被视为过期的日期/时间。有关新鲜度模型的进一步讨论，请参见第 4.2 节。

Expires 字段的存在并不意味着原始资源将在该时间之前、之时或之后更改或停止存在。

Expires 值是 HTTP-date 时间戳，如 [RFC7231] 的第 7.1.1.1 节中所定义。

Expires = HTTP-date

例如：

Expires: Thu, 01 Dec 1994 16:00:00 GMT

缓存接收方必须将无效的日期格式（尤其是值 "0"）解释为表示过去的时间（即 "已过期"）。

如果响应包含带有 max-age 指令（第 5.2.2.8 节）的 Cache-Control 字段，则接收方必须忽略 Expires 字段。同样，如果响应包含 s-maxage 指令（第 5.2.2.9 节），则共享缓存接收方必须忽略 Expires 字段。在这两种情况下，Expires 中的值仅适用于尚未实现 Cache-Control 字段的接收方。

没有时钟的源服务器不得生成 Expires 字段，除非其值表示过去的固定时间（始终过期）或其值已由具有可靠时钟的系统或用户与资源关联。

从历史上看，HTTP 要求 Expires 字段值不超过未来一年。虽然不再禁止更长的新鲜度生命周期，但已证明极大的值会导致问题（例如，由于使用 32 位整数表示时间值而导致的时钟溢出），并且许多缓存会更早地驱逐响应。

5.4. Pragma​

"Pragma" 头字段允许与 HTTP/1.0 缓存向后兼容，以便客户端可以指定他们将理解的 "no-cache" 请求（因为 Cache-Control 直到 HTTP/1.1 才定义）。当 Cache-Control 头字段也存在并在请求中被理解时，Pragma 将被忽略。

在 HTTP/1.0 中，Pragma 被定义为接收方的实现指定指令的可扩展字段。本规范弃用此类扩展以提高互操作性。

Pragma           = 1#pragma-directive
pragma-directive = "no-cache" / extension-pragma
extension-pragma = token [ "=" ( token / quoted-string ) ]

当请求中不存在 Cache-Control 头字段时，缓存必须将 no-cache 请求 pragma 指令视为具有与 "Cache-Control: no-cache" 存在相同的效果（参见第 5.2.1 节）。

当发送 no-cache 请求时，客户端应该包含 pragma 和 cache-control 指令，除非有意省略 Cache-Control: no-cache 以针对 HTTP/1.1 缓存的其他 Cache-Control 响应指令。例如：

GET / HTTP/1.1
Host: www.example.com
Cache-Control: max-age=30
Pragma: no-cache

将约束 HTTP/1.1 缓存提供不超过 30 秒的响应，同时阻止不理解 Cache-Control 的实现提供缓存的响应。

注意： 因为响应中 "Pragma: no-cache" 的含义未指定，所以它不能为它们提供可靠的 "Cache-Control: no-cache" 替代品。

5.5. Warning​

"Warning" 头字段用于携带有关消息的状态或转换的附加信息，这些信息可能不会反映在状态码中。此信息通常用于警告由缓存操作或应用于消息有效负载的转换引入的可能的不正确性。

警告可以用于其他目的，无论是与缓存相关还是其他目的。使用警告而不是错误状态码，将这些响应与真正的失败区分开来。

Warning 头字段通常可以应用于任何消息，但某些 warn-code 特定于缓存，只能应用于响应消息。

Warning       = 1#warning-value

warning-value = warn-code SP warn-agent SP warn-text
                                      [ SP warn-date ]

warn-code  = 3DIGIT
warn-agent = ( uri-host [ ":" port ] ) / pseudonym
                ; the name or pseudonym of the server adding
                ; the Warning header field, for use in debugging
                ; a single "-" is recommended when agent unknown
warn-text  = quoted-string
warn-date  = DQUOTE HTTP-date DQUOTE

可以在响应中生成多个警告（由源服务器或缓存生成），包括具有相同 warn-code 编号但仅在 warn-text 中不同的多个警告。

接收一个或多个 Warning 头字段的用户代理应该按照它们在响应中出现的顺序通知用户尽可能多的警告。鼓励生成多个 Warning 头字段的发送方在考虑此用户代理行为的情况下对它们进行排序。生成新 Warning 头字段的发送方必须在任何现有 Warning 头字段之后附加它们。

警告被分配三位数的 warn-code。第一位数字指示在验证后是否需要从存储的响应中删除警告：

  • 1xx warn-code 描述响应的新鲜度或验证状态，因此它们必须在验证后由缓存删除。它们只能由缓存在验证缓存条目时生成，并且不得在任何其他情况下生成。

  • 2xx warn-code 描述表示的某些方面，这些方面不会通过验证来纠正（例如，表示的有损压缩），并且它们不得在验证后由缓存删除，除非发送完整响应，在这种情况下它们必须被删除。

如果发送方在要发送给已知仅实现 HTTP/1.0 的接收方的消息中生成一个或多个 1xx warn-code，则发送方必须在每个相应的 warning-value 中包含与消息中的 Date 头字段匹配的 warn-date。例如：

HTTP/1.1 200 OK
Date: Sat, 25 Aug 2012 23:34:45 GMT
Warning: 112 - "network down" "Sat, 25 Aug 2012 23:34:45 GMT"

警告具有描述错误的附带 warn-text，例如用于日志记录。它仅是建议性的，其内容不影响 warn-code 的解释。

如果使用、评估或显示 Warning 头字段的接收方接收到与同一消息中的 Date 值不同的 warn-date，则接收方必须在存储、转发或使用消息之前排除包含该 warn-date 的 warning-value。这允许接收方排除在缓存验证后不当保留的 warning-value。如果排除了所有 warning-value，则接收方也必须排除 Warning 头字段。

本规范定义了以下 warn-code，每个都有英文推荐的 warn-text 及其含义的描述。定义其他 warn code 的过程在第 7.2.1 节中描述。

5.5.1. Warning: 110 - "Response is Stale"​

每当发送的响应过期时，缓存都应该生成此警告。

5.5.2. Warning: 111 - "Revalidation Failed"​

当由于无法到达服务器而尝试验证响应失败时发送过期响应时，缓存应该生成此警告。

5.5.3. Warning: 112 - "Disconnected Operation"​

如果缓存有意在一段时间内与网络的其余部分断开连接，则应该生成此警告。

5.5.4. Warning: 113 - "Heuristic Expiration"​

如果缓存启发式地选择了大于 24 小时的新鲜度生命周期并且响应的年龄大于 24 小时，则应该生成此警告。

5.5.5. Warning: 199 - "Miscellaneous Warning"​

警告文本可以包含要呈现给人类用户或记录的任意信息。接收此警告的系统不得采取任何自动操作，除了向用户呈现警告。

5.5.6. Warning: 214 - "Transformation Applied"​

如果代理对表示应用任何转换（例如更改 content-coding、media-type 或修改表示数据），则必须添加此 Warning 代码，除非此 Warning 代码已出现在响应中。

5.5.7. Warning: 299 - "Miscellaneous Persistent Warning"​

警告文本可以包含要呈现给人类用户或记录的任意信息。接收此警告的系统不得采取任何自动操作。