6. History Lists (历史列表)

User agents often have history mechanisms, such as "Back" buttons and history lists, that can be used to redisplay a representation retrieved earlier in a session.

用户代理通常具有历史机制,例如"后退"按钮和历史列表,可用于重新显示会话中较早检索的表示。

The freshness model (Section 4.2) does not necessarily apply to history mechanisms. That is, a history mechanism can display a previous representation even if it has expired.

新鲜度模型(第4.2节)不一定适用于历史机制。也就是说,历史机制可以显示先前的表示,即使它已过期。

This does not prohibit the history mechanism from telling the user that a view might be stale or from honoring cache directives (e.g., Cache-Control: no-store).

这并不禁止历史机制告诉用户视图可能已过期或遵守缓存指令(例如,Cache-Control: no-store)。

7. IANA Considerations (IANA考虑事项)

7.1. Cache Directive Registry (缓存指令注册表)

The "Hypertext Transfer Protocol (HTTP) Cache Directive Registry" defines the namespace for the cache directives. It has been created and is now maintained at <http://www.iana.org/assignments/http-cache-directives>.

"超文本传输协议(HTTP)缓存指令注册表"定义了缓存指令的命名空间。它已创建并现在维护在<http://www.iana.org/assignments/http-cache-directives&gt;。

7.1.1. Procedure (程序)

A registration MUST include the following fields:

注册必须包括以下字段:

• Cache Directive Name (缓存指令名称)
• Pointer to specification text (指向规范文本的指针)

Values to be added to this namespace require IETF Review (see [RFC5226], Section 4.1).

要添加到此命名空间的值需要IETF审查(参见[RFC5226],第4.1节)。

7.1.2. Considerations for New Cache Control Directives (新缓存控制指令的考虑事项)

New extension directives ought to consider defining:

新的扩展指令应该考虑定义:

• What it means for a directive to be specified multiple times,

• 指令被多次指定意味着什么,

• When the directive does not take an argument, what it means when an argument is present,

• 当指令不接受参数时,存在参数意味着什么,

• When the directive requires an argument, what it means when it is missing,

• 当指令需要参数时,缺少参数意味着什么,

• Whether the directive is specific to requests, responses, or able to be used in either.

• 指令是特定于请求、响应还是可以在两者中使用。

See also Section 5.2.3.

另请参见第5.2.3节。

7.1.3. Registrations (注册)

The registry has been populated with the registrations below:

注册表已填充以下注册:

Cache Directive	Reference
max-age	Section 5.2.1.1, Section 5.2.2.8
max-stale	Section 5.2.1.2
min-fresh	Section 5.2.1.3
must-revalidate	Section 5.2.2.1
no-cache	Section 5.2.1.4, Section 5.2.2.2
no-store	Section 5.2.1.5, Section 5.2.2.3
no-transform	Section 5.2.1.6, Section 5.2.2.4
only-if-cached	Section 5.2.1.7
private	Section 5.2.2.6
proxy-revalidate	Section 5.2.2.7
public	Section 5.2.2.5
s-maxage	Section 5.2.2.9
stale-if-error	[RFC5861], Section 4
stale-while-revalidate	[RFC5861], Section 3

7.2. Warn Code Registry (警告代码注册表)

The "Hypertext Transfer Protocol (HTTP) Warn Codes" registry defines the namespace for warn codes. It has been created and is now maintained at http://www.iana.org/assignments/http-warn-codes.

"超文本传输协议(HTTP)警告代码"注册表定义了警告代码的命名空间。它已创建并现在维护在http://www.iana.org/assignments/http-warn-codes。

7.2.1. Procedure (程序)

A registration MUST include the following fields:

注册必须包括以下字段:

• Warn Code (3 digits) (警告代码(3位数字))
• Short Description (简短描述)
• Pointer to specification text (指向规范文本的指针)

Values to be added to this namespace require IETF Review (see [RFC5226], Section 4.1).

要添加到此命名空间的值需要IETF审查(参见[RFC5226],第4.1节)。

7.2.2. Registrations (注册)

The registry has been populated with the registrations below:

注册表已填充以下注册:

Warn Code	Short Description	Reference
110	Response is Stale	Section 5.5.1
111	Revalidation Failed	Section 5.5.2
112	Disconnected Operation	Section 5.5.3
113	Heuristic Expiration	Section 5.5.4
199	Miscellaneous Warning	Section 5.5.5
214	Transformation Applied	Section 5.5.6
299	Miscellaneous Persistent Warning	Section 5.5.7

7.3. Header Field Registration (头字段注册)

HTTP header fields are registered within the "Message Headers" registry maintained at http://www.iana.org/assignments/message-headers/.

HTTP头字段在http://www.iana.org/assignments/message-headers/维护的"消息头"注册表中注册。

This document defines the following HTTP header fields, so the "Permanent Message Header Field Names" registry has been updated accordingly (see [BCP90]).

本文档定义了以下HTTP头字段,因此"永久消息头字段名称"注册表已相应更新(参见[BCP90])。

Header Field Name	Protocol	Status	Reference
Age	http	standard	Section 5.1
Cache-Control	http	standard	Section 5.2
Expires	http	standard	Section 5.3
Pragma	http	standard	Section 5.4
Warning	http	standard	Section 5.5

The change controller is: "IETF ([email protected]) - Internet Engineering Task Force".

变更控制者是: "IETF ([email protected]) - 互联网工程任务组"。

8. Security Considerations (安全考虑)

This section is meant to inform developers, information providers, and users of known security concerns specific to HTTP caching. More general security considerations are addressed in HTTP messaging [RFC7230] and semantics [RFC7231].

本节旨在告知开发人员、信息提供者和用户有关HTTP缓存特定的已知安全问题。更一般的安全考虑在HTTP消息传递[RFC7230]和语义[RFC7231]中讨论。

Caches expose additional potential vulnerabilities, since the contents of the cache represent an attractive target for malicious exploitation. Because cache contents persist after an HTTP request is complete, an attack on the cache can reveal information long after a user believes that the information has been removed from the network. Therefore, cache contents need to be protected as sensitive information.

缓存暴露了额外的潜在漏洞,因为缓存的内容代表了恶意利用的有吸引力的目标。由于缓存内容在HTTP请求完成后仍然存在,因此对缓存的攻击可以在用户认为信息已从网络中删除很久之后泄露信息。因此,缓存内容需要作为敏感信息受到保护。

In particular, various attacks might be amplified by being stored in a shared cache; such "cache poisoning" attacks use the cache to distribute a malicious payload to many clients, and are especially effective when an attacker can use implementation flaws, elevated privileges, or other techniques to insert such a response into a cache. One common attack vector for cache poisoning is to exploit differences in message parsing on proxies and in user agents; see Section 3.3.3 of [RFC7230] for the relevant requirements.

特别是,各种攻击可能会通过存储在共享缓存中而被放大; 这种"缓存投毒"攻击使用缓存将恶意有效负载分发给许多客户端,并且当攻击者可以使用实现缺陷、提升的权限或其他技术将此类响应插入缓存时特别有效。缓存投毒的一个常见攻击向量是利用代理和用户代理中消息解析的差异; 有关相关要求,请参见[RFC7230]的第3.3.3节。

Likewise, implementation flaws (as well as misunderstanding of cache operation) might lead to caching of sensitive information (e.g., authentication credentials) that is thought to be private, exposing it to unauthorized parties.

同样,实现缺陷(以及对缓存操作的误解)可能导致缓存被认为是私有的敏感信息(例如,身份验证凭据),从而将其暴露给未经授权的方。

Furthermore, the very use of a cache can bring about privacy concerns. For example, if two users share a cache, and the first one browses to a site, the second may be able to detect that the other has been to that site, because the resources from it load more quickly, thanks to the cache.

此外,缓存的使用本身就可能带来隐私问题。例如,如果两个用户共享一个缓存,并且第一个用户浏览到一个站点,则第二个用户可能能够检测到另一个用户去过该站点,因为由于缓存,来自该站点的资源加载得更快。

Note that the Set-Cookie response header field [RFC6265] does not inhibit caching; a cacheable response with a Set-Cookie header field can be (and often is) used to satisfy subsequent requests to caches. Servers who wish to control caching of these responses are encouraged to emit appropriate Cache-Control response header fields.

请注意,Set-Cookie响应头字段[RFC6265]不会抑制缓存; 具有Set-Cookie头字段的可缓存响应可以(并且经常)用于满足对缓存的后续请求。希望控制这些响应的缓存的服务器被鼓励发出适当的Cache-Control响应头字段。

9. Acknowledgments (致谢)

See Section 10 of [RFC7230].

参见[RFC7230]的第10节。

10. References (参考文献)

10.1. Normative References (规范性参考文献)

• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

• [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

• [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014.

• [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.

• [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, June 2014.

• [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, June 2014.

• [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014.

10.2. Informative References (信息性参考文献)

• [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.

• [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

• [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

• [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale Content", RFC 5861, April 2010.

• [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.

• [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011.

Appendix A. Changes from RFC 2616 (与RFC 2616的变更)

The specification has been substantially rewritten for clarity.

规范已经过大幅重写以提高清晰度。

The conditions under which an authenticated response can be cached have been clarified. (Section 3.2)

已认证响应可以被缓存的条件已被澄清。(第3.2节)

New status codes can now define that caches are allowed to use heuristic freshness with them. Caches are now allowed to calculate heuristic freshness for URIs with query components. (Section 4.2.2)

新的状态码现在可以定义允许缓存对它们使用启发式新鲜度。现在允许缓存为具有查询组件的URI计算启发式新鲜度。(第4.2.2节)

The algorithm for calculating age is now less conservative. Caches are now required to handle dates with time zones as if they're invalid, because it's not possible to accurately guess. (Section 4.2.3)

计算年龄的算法现在不那么保守。现在要求缓存将带有时区的日期视为无效,因为无法准确猜测。(第4.2.3节)

The Content-Location response header field is no longer used to determine the appropriate response to use when validating. (Section 4.3)

Content-Location响应头字段不再用于确定验证时使用的适当响应。(第4.3节)

The algorithm for selecting a cached negotiated response to use has been clarified in several ways. In particular, it now explicitly allows header-specific canonicalization when processing selecting header fields. (Section 4.1)

选择要使用的缓存协商响应的算法已在几个方面得到澄清。特别是,它现在在处理选择头字段时明确允许特定于头的规范化。(第4.1节)

Requirements regarding denial-of-service attack avoidance when performing invalidation have been clarified. (Section 4.4)

执行失效时关于避免拒绝服务攻击的要求已被澄清。(第4.4节)

Cache invalidation only occurs when a successful response is received. (Section 4.4)

缓存失效仅在接收到成功响应时发生。(第4.4节)

Cache directives are explicitly defined to be case-insensitive. Handling of multiple instances of cache directives when only one is expected is now defined. (Section 5.2)

缓存指令被明确定义为不区分大小写。现在定义了当只期望一个缓存指令时处理多个缓存指令实例的方式。(第5.2节)

The "no-store" request directive doesn't apply to responses; i.e., a cache can satisfy a request with no-store on it and does not invalidate it. (Section 5.2.1.5)

"no-store"请求指令不适用于响应; 即,缓存可以满足带有no-store的请求,并且不会使其失效。(第5.2.1.5节)

The qualified forms of the private and no-cache cache directives are noted to not be widely implemented; for example, "private=foo" is interpreted by many caches as simply "private". Additionally, the meaning of the qualified form of no-cache has been clarified. (Section 5.2.2)

private和no-cache缓存指令的限定形式被注意到未被广泛实现; 例如,"private=foo"被许多缓存简单地解释为"private"。此外,no-cache的限定形式的含义已被澄清。(第5.2.2节)

The "no-cache" response directive's meaning has been clarified. (Section 5.2.2.2)

"no-cache"响应指令的含义已被澄清。(第5.2.2.2节)

The one-year limit on Expires header field values has been removed; instead, the reasoning for using a sensible value is given. (Section 5.3)

Expires头字段值的一年限制已被删除; 相反,给出了使用合理值的理由。(第5.3节)

The Pragma header field is now only defined for backwards compatibility; future pragmas are deprecated. (Section 5.4)

Pragma头字段现在仅为向后兼容性而定义; 未来的pragma已被弃用。(第5.4节)

Some requirements regarding production and processing of the Warning header fields have been relaxed, as it is not widely implemented. Furthermore, the Warning header field no longer uses RFC 2047 encoding, nor does it allow multiple languages, as these aspects were not implemented. (Section 5.5)

关于Warning头字段的生成和处理的一些要求已被放宽,因为它未被广泛实现。此外,Warning头字段不再使用RFC 2047编码,也不允许多种语言,因为这些方面未被实现。(第5.5节)

This specification introduces the Cache Directive and Warn Code Registries, and defines considerations for new cache directives. (Section 7.1 and Section 7.2)

本规范引入了缓存指令和警告代码注册表,并定义了新缓存指令的考虑事项。(第7.1节和第7.2节)

Appendix B. Imported ABNF (导入的ABNF)

The following core rules are included by reference, as defined in Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII character).

以下核心规则通过引用包含,如[RFC5234]的附录B.1中所定义: ALPHA(字母)、CR(回车)、CRLF(CR LF)、CTL(控制)、DIGIT(十进制0-9)、DQUOTE(双引号)、HEXDIG(十六进制0-9/A-F/a-f)、LF(换行)、OCTET(任何8位数据序列)、SP(空格)和VCHAR(任何可见的US-ASCII字符)。

The rules below are defined in [RFC7230]:

以下规则在[RFC7230]中定义:

OWS           = <OWS, see [RFC7230], Section 3.2.3>
field-name    = <field-name, see [RFC7230], Section 3.2>
quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
token         = <token, see [RFC7230], Section 3.2.6>

port          = <port, see [RFC7230], Section 2.7>
pseudonym     = <pseudonym, see [RFC7230], Section 5.7.1>
uri-host      = <uri-host, see [RFC7230], Section 2.7>

The rules below are defined in other parts:

以下规则在其他部分中定义:

HTTP-date     = <HTTP-date, see [RFC7231], Section 7.1.1.1>

Appendix C. Collected ABNF (收集的ABNF)

In the collected ABNF below, list rules are expanded as per Section 1.2 of [RFC7230].

在下面收集的ABNF中,列表规则按照[RFC7230]的第1.2节进行扩展。

Age = delta-seconds

Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS
 cache-directive ] )

Expires = HTTP-date

HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1>

OWS = <OWS, see [RFC7230], Section 3.2.3>

Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS
 pragma-directive ] )

Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ]
 )

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

delta-seconds = 1*DIGIT

extension-pragma = token [ "=" ( token / quoted-string ) ]

field-name = <field-name, see [RFC7230], Section 3.2>

port = <port, see [RFC7230], Section 2.7>
pragma-directive = "no-cache" / extension-pragma
pseudonym = <pseudonym, see [RFC7230], Section 5.7.1>

quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>

token = <token, see [RFC7230], Section 3.2.6>

uri-host = <uri-host, see [RFC7230], Section 2.7>

warn-agent = ( uri-host [ ":" port ] ) / pseudonym
warn-code = 3DIGIT
warn-date = DQUOTE HTTP-date DQUOTE
warn-text = quoted-string
warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date
 ]

---

Authors' Addresses (作者地址)

Roy T. Fielding (editor)
Adobe Systems Incorporated
345 Park Ave
San Jose, CA 95110
USA

EMail: [email protected]
URI: http://roy.gbiv.com/

Mark Nottingham (editor)
Akamai

EMail: [email protected]
URI: http://www.mnot.net/

Julian F. Reschke (editor)
greenbytes GmbH
Hafenweg 16
Muenster, NW 48155
Germany

EMail: [email protected]
URI: http://greenbytes.de/tech/webdav/