5. Header Field Definitions (头字段定义)
This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.
本节定义与缓存相关的HTTP/1.1头字段的语法和语义。
5.1. Age
The "Age" header field conveys the sender's estimate of the amount of time since the response was generated or successfully validated at the origin server. Age values are calculated as specified in Section 4.2.3.
"Age"头字段传达发送方对自源服务器生成或成功验证响应以来的时间量的估计。Age值按第4.2.3节中指定的方式计算。
Age = delta-seconds
The Age field-value is a non-negative integer, representing time in seconds (see Section 1.2.1).
Age字段值是非负整数,表示以秒为单位的时间(参见第1.2.1节)。
The presence of an Age header field implies that the response was not generated or validated by the origin server for this request. However, lack of an Age header field does not imply the origin was contacted, since the response might have been received from an HTTP/1.0 cache that does not implement Age.
Age头字段的存在意味着响应不是由源服务器为此请求生成或验证的。但是,缺少Age头字段并不意味着联系了源服务器,因为响应可能是从不实现Age的HTTP/1.0缓存接收的。
5.2. Cache-Control
The "Cache-Control" header field is used to specify directives for caches along the request/response chain. Such cache directives are unidirectional in that the presence of a directive in a request does not imply that the same directive is to be given in the response.
"Cache-Control"头字段用于为请求/响应链上的缓存指定指令。此类缓存指令是单向的,即请求中存在指令并不意味着响应中也要给出相同的指令。
A cache MUST obey the requirements of the Cache-Control directives defined in this section. See Section 5.2.3 for information about how Cache-Control directives defined elsewhere are handled.
缓存必须遵守本节中定义的Cache-Control指令的要求。有关如何处理在其他地方定义的Cache-Control指令的信息,请参见第5.2.3节。
注意: 某些HTTP/1.0缓存可能不实现Cache-Control。
A proxy, whether or not it implements a cache, MUST pass cache directives through in forwarded messages, regardless of their significance to that application, since the directives might be applicable to all recipients along the request/response chain. It is not possible to target a directive to a specific cache.
代理,无论是否实现缓存,都必须在转发的消息中传递缓存指令,无论这些指令对该应用程序的重要性如何,因为这些指令可能适用于请求/响应链上的所有接收方。不可能将指令定向到特定缓存。
Cache directives are identified by a token, to be compared case-insensitively, and have an optional argument, that can use both token and quoted-string syntax. For the directives defined below that define arguments, recipients ought to accept both forms, even if one is documented to be preferred. For any directive not defined by this specification, a recipient MUST accept both forms.
缓存指令由标记标识,不区分大小写进行比较,并具有可选参数,该参数可以使用标记和引用字符串语法。对于下面定义的定义参数的指令,接收方应该接受两种形式,即使记录了首选其中一种。对于本规范未定义的任何指令,接收方必须接受两种形式。
Cache-Control = 1#cache-directive
cache-directive = token [ "=" ( token / quoted-string ) ]
For the cache directives defined below, no argument is defined (nor allowed) unless stated otherwise.
对于下面定义的缓存指令,除非另有说明,否则不定义(也不允许)参数。
5.2.1. Request Cache-Control Directives (请求缓存控制指令)
5.2.1.1. max-age
Argument syntax:
delta-seconds (see Section 1.2.1)
The "max-age" request directive indicates that the client is unwilling to accept a response whose age is greater than the specified number of seconds. Unless the max-stale request directive is also present, the client is not willing to accept a stale response.
"max-age"请求指令表示客户端不愿意接受年龄大于指定秒数的响应。除非还存在max-stale请求指令,否则客户端不愿意接受过期响应。
This directive uses the token form of the argument syntax: e.g., 'max-age=5' not 'max-age="5"'. A sender SHOULD NOT generate the quoted-string form.
此指令使用参数语法的标记形式: 例如,'max-age=5'而不是'max-age="5"'。发送方不应该生成引用字符串形式。
5.2.1.2. max-stale
Argument syntax:
delta-seconds (see Section 1.2.1)
The "max-stale" request directive indicates that the client is willing to accept a response that has exceeded its freshness lifetime. If max-stale is assigned a value, then the client is willing to accept a response that has exceeded its freshness lifetime by no more than the specified number of seconds. If no value is assigned to max-stale, then the client is willing to accept a stale response of any age.
"max-stale"请求指令表示客户端愿意接受已超过其新鲜度生命周期的响应。如果为max-stale分配了值,则客户端愿意接受超过其新鲜度生命周期不超过指定秒数的响应。如果未为max-stale分配值,则客户端愿意接受任何年龄的过期响应。
This directive uses the token form of the argument syntax: e.g., 'max-stale=10' not 'max-stale="10"'. A sender SHOULD NOT generate the quoted-string form.
此指令使用参数语法的标记形式: 例如,'max-stale=10'而不是'max-stale="10"'。发送方不应该生成引用字符串形式。
5.2.1.3. min-fresh
Argument syntax:
delta-seconds (see Section 1.2.1)
The "min-fresh" request directive indicates that the client is willing to accept a response whose freshness lifetime is no less than its current age plus the specified time in seconds. That is, the client wants a response that will still be fresh for at least the specified number of seconds.
"min-fresh"请求指令表示客户端愿意接受其新鲜度生命周期不小于其当前年龄加上指定秒数的响应。也就是说,客户端想要一个至少在指定秒数内仍然新鲜的响应。
This directive uses the token form of the argument syntax: e.g., 'min-fresh=20' not 'min-fresh="20"'. A sender SHOULD NOT generate the quoted-string form.
此指令使用参数语法的标记形式: 例如,'min-fresh=20'而不是'min-fresh="20"'。发送方不应该生成引用字符串形式。
5.2.1.4. no-cache
The "no-cache" request directive indicates that a cache MUST NOT use a stored response to satisfy the request without successful validation on the origin server.
"no-cache"请求指令表示缓存不得在源服务器上成功验证的情况下使用存储的响应来满足请求。
5.2.1.5. no-store
The "no-store" request directive indicates that a cache MUST NOT store any part of either this request or any response to it. This directive applies to both private and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.
"no-store"请求指令表示缓存不得存储此请求或对其的任何响应的任何部分。此指令适用于私有缓存和共享缓存。在此上下文中,"不得存储"意味着缓存不得有意将信息存储在非易失性存储中,并且必须尽最大努力在转发后尽快从易失性存储中删除信息。
This directive is NOT a reliable or sufficient mechanism for ensuring privacy. In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping.
此指令不是确保隐私的可靠或充分机制。特别是,恶意或受损的缓存可能不识别或遵守此指令,并且通信网络可能容易受到窃听。
Note that if a request containing this directive is satisfied from a cache, the no-store request directive does not apply to the already stored response.
请注意,如果从缓存中满足包含此指令的请求,则no-store请求指令不适用于已存储的响应。
5.2.1.6. no-transform
The "no-transform" request directive indicates that an intermediary (whether or not it implements a cache) MUST NOT transform the payload, as defined in Section 5.7.2 of [RFC7230].
"no-transform"请求指令表示中介(无论是否实现缓存)不得转换有效负载,如[RFC7230]的第5.7.2节中所定义。
5.2.1.7. only-if-cached
The "only-if-cached" request directive indicates that the client only wishes to obtain a stored response. If it receives this directive, a cache SHOULD either respond using a stored response that is consistent with the other constraints of the request, or respond with a 504 (Gateway Timeout) status code. If a group of caches is being operated as a unified system with good internal connectivity, a member cache MAY forward such a request within that group of caches.
"only-if-cached"请求指令表示客户端仅希望获取存储的响应。如果缓存接收到此指令,则应该使用与请求的其他约束一致的存储响应进行响应,或使用504 (Gateway Timeout)状态码进行响应。如果一组缓存作为具有良好内部连接的统一系统运行,则成员缓存可以在该组缓存内转发此类请求。
5.2.2. Response Cache-Control Directives (响应缓存控制指令)
5.2.2.1. must-revalidate
The "must-revalidate" response directive indicates that once it has become stale, a cache MUST NOT use the response to satisfy subsequent requests without successful validation on the origin server.
"must-revalidate"响应指令表示一旦响应变得过期,缓存不得在源服务器上成功验证的情况下使用该响应来满足后续请求。
The must-revalidate directive is necessary to support reliable operation for certain protocol features. In all circumstances a cache MUST obey the must-revalidate directive; in particular, if a cache cannot reach the origin server for any reason, it MUST generate a 504 (Gateway Timeout) response.
must-revalidate指令对于支持某些协议功能的可靠操作是必要的。在所有情况下,缓存都必须遵守must-revalidate指令; 特别是,如果缓存由于任何原因无法到达源服务器,它必须生成504 (Gateway Timeout)响应。
The must-revalidate directive ought to be used by servers if and only if failure to validate a request on the representation could result in incorrect operation, such as a silently unexecuted financial transaction.
当且仅当未能验证表示上的请求可能导致不正确的操作(例如静默未执行的金融交易)时,服务器才应该使用must-revalidate指令。
5.2.2.2. no-cache
Argument syntax:
#field-name
The "no-cache" response directive indicates that the response MUST NOT be used to satisfy a subsequent request without successful validation on the origin server. This allows an origin server to prevent a cache from using it to satisfy a request without contacting it, even by caches that have been configured to send stale responses.
"no-cache"响应指令表示响应不得在源服务器上成功验证的情况下用于满足后续请求。这允许源服务器防止缓存在不联系它的情况下使用它来满足请求,即使是已配置为发送过期响应的缓存。
If the no-cache response directive specifies one or more field-names, then a cache MAY use the response to satisfy a subsequent request, subject to any other restrictions on caching. However, any header fields in the response that have the field-name(s) listed MUST NOT be sent in the response to a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent the re-use of certain header fields in a response, while still allowing caching of the rest of the response.
如果no-cache响应指令指定一个或多个字段名称,则缓存可以使用响应来满足后续请求,但须遵守对缓存的任何其他限制。但是,响应中具有列出的字段名称的任何头字段不得在对后续请求的响应中发送,除非与源服务器成功重新验证。这允许源服务器防止响应中某些头字段的重用,同时仍允许缓存响应的其余部分。
The field-names given are not limited to the set of header fields defined by this specification. Field names are case-insensitive.
给定的字段名称不限于本规范定义的头字段集。字段名称不区分大小写。
This directive uses the quoted-string form of the argument syntax. A sender SHOULD NOT generate the token form (even if quoting appears not to be needed for single-entry lists).
此指令使用参数语法的引用字符串形式。发送方不应该生成标记形式(即使对于单条目列表似乎不需要引用)。
注意: 尽管已向后移植到许多实现,但某些HTTP/1.0缓存不会识别或遵守此指令。此外,带有字段名称的no-cache响应指令通常被缓存处理为接收到不合格的no-cache指令; 即,未广泛实现对合格形式的特殊处理。
5.2.2.3. no-store
The "no-store" response directive indicates that a cache MUST NOT store any part of either the immediate request or response. This directive applies to both private and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.
"no-store"响应指令表示缓存不得存储立即请求或响应的任何部分。此指令适用于私有缓存和共享缓存。在此上下文中,"不得存储"意味着缓存不得有意将信息存储在非易失性存储中,并且必须尽最大努力在转发后尽快从易失性存储中删除信息。
This directive is NOT a reliable or sufficient mechanism for ensuring privacy. In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping.
此指令不是确保隐私的可靠或充分机制。特别是,恶意或受损的缓存可能不识别或遵守此指令,并且通信网络可能容易受到窃听。
5.2.2.4. no-transform
The "no-transform" response directive indicates that an intermediary (regardless of whether it implements a cache) MUST NOT transform the payload, as defined in Section 5.7.2 of [RFC7230].
"no-transform"响应指令表示中介(无论是否实现缓存)不得转换有效负载,如[RFC7230]的第5.7.2节中所定义。
5.2.2.5. public
The "public" response directive indicates that any cache MAY store the response, even if the response would normally be non-cacheable or cacheable only within a private cache. (See Section 3.2 for additional details related to the use of public in response to a request containing Authorization, and Section 3 for details of how public affects responses that would normally not be stored, due to their status codes not being defined as cacheable by default; see Section 4.2.2.)
"public"响应指令表示任何缓存都可以存储响应,即使响应通常是不可缓存的或仅在私有缓存中可缓存。(有关响应包含Authorization的请求时使用public的其他详细信息,请参见第3.2节,有关public如何影响通常不会存储的响应(由于其状态码默认未定义为可缓存)的详细信息,请参见第3节; 参见第4.2.2节。)
5.2.2.6. private
Argument syntax:
#field-name
The "private" response directive indicates that the response message is intended for a single user and MUST NOT be stored by a shared cache. A private cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable.
"private"响应指令表示响应消息旨在供单个用户使用,并且不得由共享缓存存储。私有缓存可以存储响应并将其重用于以后的请求,即使响应通常是不可缓存的。
If the private response directive specifies one or more field-names, this requirement is limited to the field-values associated with the listed response header fields. That is, a shared cache MUST NOT store the specified field-names(s), whereas it MAY store the remainder of the response message.
如果private响应指令指定一个或多个字段名称,则此要求仅限于与列出的响应头字段关联的字段值。也就是说,共享缓存不得存储指定的字段名称,而可以存储响应消息的其余部分。
The field-names given are not limited to the set of header fields defined by this specification. Field names are case-insensitive.
给定的字段名称不限于本规范定义的头字段集。字段名称不区分大小写。
This directive uses the quoted-string form of the argument syntax. A sender SHOULD NOT generate the token form (even if quoting appears not to be needed for single-entry lists).
此指令使用参数语法的引用字符串形式。发送方不应该生成标记形式(即使对于单条目列表似乎不需要引用)。
注意: "private"一词的这种用法仅控制响应可以存储的位置; 它不能确保消息内容的隐私。此外,带有字段名称的private响应指令通常被缓存处理为接收到不合格的private指令; 即,未广泛实现对合格形式的特殊处理。
5.2.2.7. proxy-revalidate
The "proxy-revalidate" response directive has the same meaning as the must-revalidate response directive, except that it does not apply to private caches.
"proxy-revalidate"响应指令与must-revalidate响应指令具有相同的含义,只是它不适用于私有缓存。
5.2.2.8. max-age
Argument syntax:
delta-seconds (see Section 1.2.1)
The "max-age" response directive indicates that the response is to be considered stale after its age is greater than the specified number of seconds.
"max-age"响应指令表示在其年龄大于指定秒数后,响应将被视为过期。
This directive uses the token form of the argument syntax: e.g., 'max-age=5' not 'max-age="5"'. A sender SHOULD NOT generate the quoted-string form.
此指令使用参数语法的标记形式: 例如,'max-age=5'而不是'max-age="5"'。发送方不应该生成引用字符串形式。
5.2.2.9. s-maxage
Argument syntax:
delta-seconds (see Section 1.2.1)
The "s-maxage" response directive indicates that, in shared caches, the maximum age specified by this directive overrides the maximum age specified by either the max-age directive or the Expires header field. The s-maxage directive also implies the semantics of the proxy-revalidate response directive.
"s-maxage"响应指令表示,在共享缓存中,此指令指定的最大年龄覆盖max-age指令或Expires头字段指定的最大年龄。s-maxage指令还暗示proxy-revalidate响应指令的语义。
This directive uses the token form of the argument syntax: e.g., 's-maxage=10' not 's-maxage="10"'. A sender SHOULD NOT generate the quoted-string form.
此指令使用参数语法的标记形式: 例如,'s-maxage=10'而不是's-maxage="10"'。发送方不应该生成引用字符串形式。
5.2.3. Cache Control Extensions (缓存控制扩展)
The Cache-Control header field can be extended through the use of one or more cache-extension tokens, each with an optional value. A cache MUST ignore unrecognized cache directives.
Cache-Control头字段可以通过使用一个或多个缓存扩展标记来扩展,每个标记都有一个可选值。缓存必须忽略无法识别的缓存指令。
Informational extensions (those that do not require a change in cache behavior) can be added without changing the semantics of other directives.
信息性扩展(不需要更改缓存行为的扩展)可以在不更改其他指令的语义的情况下添加。
Behavioral extensions are designed to work by acting as modifiers to the existing base of cache directives. Both the new directive and the old directive are supplied, such that applications that do not understand the new directive will default to the behavior specified by the old directive, and those that understand the new directive will recognize it as modifying the requirements associated with the old directive. In this way, extensions to the existing cache-control directives can be made without breaking deployed caches.
行为扩展旨在通过充当现有缓存指令基础的修饰符来工作。提供新指令和旧指令,以便不理解新指令的应用程序将默认为旧指令指定的行为,而理解新指令的应用程序将识别它为修改与旧指令关联的要求。通过这种方式,可以在不破坏已部署缓存的情况下对现有缓存控制指令进行扩展。
For example, consider a hypothetical new response directive called "community" that acts as a modifier to the private directive: in addition to private caches, any cache that is shared only by members of the named community is allowed to cache the response. An origin server wishing to allow the UCI community to use an otherwise private response in their shared cache(s) could do so by including
例如,考虑一个名为"community"的假设新响应指令,它充当private指令的修饰符: 除了私有缓存之外,仅由命名社区成员共享的任何缓存都允许缓存响应。希望允许UCI社区在其共享缓存中使用原本私有的响应的源服务器可以通过包含以下内容来实现:
Cache-Control: private, community="UCI"
A cache that recognizes such a community cache-extension could broaden its behavior in accordance with that extension. A cache that does not recognize the community cache-extension would ignore it and adhere to the private directive.
识别此类社区缓存扩展的缓存可以根据该扩展扩大其行为。不识别社区缓存扩展的缓存将忽略它并遵守private指令。
5.3. Expires
The "Expires" header field gives the date/time after which the response is considered stale. See Section 4.2 for further discussion of the freshness model.
"Expires"头字段给出响应被视为过期的日期/时间。有关新鲜度模型的进一步讨论,请参见第4.2节。
The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after that time.
Expires字段的存在并不意味着原始资源将在该时间之前、之时或之后更改或停止存在。
The Expires value is an HTTP-date timestamp, as defined in Section 7.1.1.1 of [RFC7231].
Expires值是HTTP-date时间戳,如[RFC7231]的第7.1.1.1节中所定义。
Expires = HTTP-date
For example
例如:
Expires: Thu, 01 Dec 1994 16:00:00 GMT
A cache recipient MUST interpret invalid date formats, especially the value "0", as representing a time in the past (i.e., "already expired").
缓存接收方必须将无效的日期格式(尤其是值"0")解释为表示过去的时间(即"已过期")。
If a response includes a Cache-Control field with the max-age directive (Section 5.2.2.8), a recipient MUST ignore the Expires field. Likewise, if a response includes the s-maxage directive (Section 5.2.2.9), a shared cache recipient MUST ignore the Expires field. In both these cases, the value in Expires is only intended for recipients that have not yet implemented the Cache-Control field.
如果响应包含带有max-age指令(第5.2.2.8节)的Cache-Control字段,则接收方必须忽略Expires字段。同样,如果响应包含s-maxage指令(第5.2.2.9节),则共享缓存接收方必须忽略Expires字段。在这两种情况下,Expires中的值仅适用于尚未实现Cache-Control字段的接收方。
An origin server without a clock MUST NOT generate an Expires field unless its value represents a fixed time in the past (always expired) or its value has been associated with the resource by a system or user with a reliable clock.
没有时钟的源服务器不得生成Expires字段,除非其值表示过去的固定时间(始终过期)或其值已由具有可靠时钟的系统或用户与资源关联。
Historically, HTTP required the Expires field-value to be no more than a year in the future. While longer freshness lifetimes are no longer prohibited, extremely large values have been demonstrated to cause problems (e.g., clock overflows due to use of 32-bit integers for time values), and many caches will evict a response far sooner than that.
从历史上看,HTTP要求Expires字段值不超过未来一年。虽然不再禁止更长的新鲜度生命周期,但已证明极大的值会导致问题(例如,由于使用32位整数表示时间值而导致的时钟溢出),并且许多缓存会更早地驱逐响应。
5.4. Pragma
The "Pragma" header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored.
"Pragma"头字段允许与HTTP/1.0缓存向后兼容,以便客户端可以指定他们将理解的"no-cache"请求(因为Cache-Control直到HTTP/1.1才定义)。当Cache-Control头字段也存在并在请求中被理解时,Pragma将被忽略。
In HTTP/1.0, Pragma was defined as an extensible field for implementation-specified directives for recipients. This specification deprecates such extensions to improve interoperability.
在HTTP/1.0中,Pragma被定义为接收方的实现指定指令的可扩展字段。本规范弃用此类扩展以提高互操作性。
Pragma = 1#pragma-directive
pragma-directive = "no-cache" / extension-pragma
extension-pragma = token [ "=" ( token / quoted-string ) ]
When the Cache-Control header field is not present in a request, caches MUST consider the no-cache request pragma-directive as having the same effect as if "Cache-Control: no-cache" were present (see Section 5.2.1).
当请求中不存在Cache-Control头字段时,缓存必须将no-cache请求pragma指令视为具有与"Cache-Control: no-cache"存在相同的效果(参见第5.2.1节)。
When sending a no-cache request, a client ought to include both the pragma and cache-control directives, unless Cache-Control: no-cache is purposefully omitted to target other Cache-Control response directives at HTTP/1.1 caches. For example:
当发送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
will constrain HTTP/1.1 caches to serve a response no older than 30 seconds, while precluding implementations that do not understand Cache-Control from serving a cached response.
将约束HTTP/1.1缓存提供不超过30秒的响应,同时阻止不理解Cache-Control的实现提供缓存的响应。
注意: 因为响应中"Pragma: no-cache"的含义未指定,所以它不能为它们提供可靠的"Cache-Control: no-cache"替代品。
5.5. Warning
The "Warning" header field is used to carry additional information about the status or transformation of a message that might not be reflected in the status code. This information is typically used to warn about possible incorrectness introduced by caching operations or transformations applied to the payload of the message.
"Warning"头字段用于携带有关消息的状态或转换的附加信息,这些信息可能不会反映在状态码中。此信息通常用于警告由缓存操作或应用于消息有效负载的转换引入的可能的不正确性。
Warnings can be used for other purposes, both cache-related and otherwise. The use of a warning, rather than an error status code, distinguishes these responses from true failures.
警告可以用于其他目的,无论是与缓存相关还是其他目的。使用警告而不是错误状态码,将这些响应与真正的失败区分开来。
Warning header fields can in general be applied to any message, however some warn-codes are specific to caches and can only be applied to response messages.
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
Multiple warnings can be generated in a response (either by the origin server or by a cache), including multiple warnings with the same warn-code number that only differ in warn-text.
可以在响应中生成多个警告(由源服务器或缓存生成),包括具有相同warn-code编号但仅在warn-text中不同的多个警告。
A user agent that receives one or more Warning header fields SHOULD inform the user of as many of them as possible, in the order that they appear in the response. Senders that generate multiple Warning header fields are encouraged to order them with this user agent behavior in mind. A sender that generates new Warning header fields MUST append them after any existing Warning header fields.
接收一个或多个Warning头字段的用户代理应该按照它们在响应中出现的顺序通知用户尽可能多的警告。鼓励生成多个Warning头字段的发送方在考虑此用户代理行为的情况下对它们进行排序。生成新Warning头字段的发送方必须在任何现有Warning头字段之后附加它们。
Warnings are assigned three digit warn-codes. The first digit indicates whether the Warning is required to be deleted from a stored response after validation:
警告被分配三位数的warn-code。第一位数字指示在验证后是否需要从存储的响应中删除Warning:
-
1xx warn-codes describe the freshness or validation status of the response, and so they MUST be deleted by a cache after validation. They can only be generated by a cache when validating a cached entry, and MUST NOT be generated in any other situation.
-
1xx warn-code描述响应的新鲜度或验证状态,因此它们必须在验证后由缓存删除。它们只能由缓存在验证缓存条目时生成,并且不得在任何其他情况下生成。
-
2xx warn-codes describe some aspect of the representation that is not rectified by a validation (for example, a lossy compression of the representation) and they MUST NOT be deleted by a cache after validation, unless a full response is sent, in which case they MUST be.
-
2xx warn-code描述表示的某些方面,这些方面不会通过验证来纠正(例如,表示的有损压缩),并且它们不得在验证后由缓存删除,除非发送完整响应,在这种情况下它们必须被删除。
If a sender generates one or more 1xx warn-codes in a message to be sent to a recipient known to implement only HTTP/1.0, the sender MUST include in each corresponding warning-value a warn-date that matches the Date header field in the message. For example:
如果发送方在要发送给已知仅实现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"
Warnings have accompanying warn-text that describes the error, e.g., for logging. It is advisory only, and its content does not affect interpretation of the warn-code.
警告具有描述错误的附带warn-text,例如用于日志记录。它仅是建议性的,其内容不影响warn-code的解释。
If a recipient that uses, evaluates, or displays Warning header fields receives a warn-date that is different from the Date value in the same message, the recipient MUST exclude the warning-value containing that warn-date before storing, forwarding, or using the message. This allows recipients to exclude warning-values that were improperly retained after a cache validation. If all of the warning-values are excluded, the recipient MUST exclude the Warning header field as well.
如果使用、评估或显示Warning头字段的接收方接收到与同一消息中的Date值不同的warn-date,则接收方必须在存储、转发或使用消息之前排除包含该warn-date的warning-value。这允许接收方排除在缓存验证后不当保留的warning-value。如果排除了所有warning-value,则接收方也必须排除Warning头字段。
The following warn-codes are defined by this specification, each with a recommended warn-text in English, and a description of its meaning. The procedure for defining additional warn codes is described in Section 7.2.1.
本规范定义了以下warn-code,每个都有英文推荐的warn-text及其含义的描述。定义其他warn code的过程在第7.2.1节中描述。
5.5.1. Warning: 110 - "Response is Stale"
A cache SHOULD generate this whenever the sent response is stale.
每当发送的响应过期时,缓存都应该生成此警告。
5.5.2. Warning: 111 - "Revalidation Failed"
A cache SHOULD generate this when sending a stale response because an attempt to validate the response failed, due to an inability to reach the server.
当由于无法到达服务器而尝试验证响应失败时发送过期响应时,缓存应该生成此警告。
5.5.3. Warning: 112 - "Disconnected Operation"
A cache SHOULD generate this if it is intentionally disconnected from the rest of the network for a period of time.
如果缓存有意在一段时间内与网络的其余部分断开连接,则应该生成此警告。
5.5.4. Warning: 113 - "Heuristic Expiration"
A cache SHOULD generate this if it heuristically chose a freshness lifetime greater than 24 hours and the response's age is greater than 24 hours.
如果缓存启发式地选择了大于24小时的新鲜度生命周期并且响应的年龄大于24小时,则应该生成此警告。
5.5.5. Warning: 199 - "Miscellaneous Warning"
The warning text can include arbitrary information to be presented to a human user or logged. A system receiving this warning MUST NOT take any automated action, besides presenting the warning to the user.
警告文本可以包含要呈现给人类用户或记录的任意信息。接收此警告的系统不得采取任何自动操作,除了向用户呈现警告。
5.5.6. Warning: 214 - "Transformation Applied"
This Warning code MUST be added by a proxy if it applies any transformation to the representation, such as changing the content-coding, media-type, or modifying the representation data, unless this Warning code already appears in the response.
如果代理对表示应用任何转换(例如更改content-coding、media-type或修改表示数据),则必须添加此Warning代码,除非此Warning代码已出现在响应中。
5.5.7. Warning: 299 - "Miscellaneous Persistent Warning"
The warning text can include arbitrary information to be presented to a human user or logged. A system receiving this warning MUST NOT take any automated action.
警告文本可以包含要呈现给人类用户或记录的任意信息。接收此警告的系统不得采取任何自动操作。