Independent Submission M. Nottingham
Request for Comments: 5861 Yahoo! Inc.
Category: Informational May 2010
ISSN: 2070-1721
Independent Submission M. Nottingham
Request for Comments: 5861 Yahoo! Inc.
Category: Informational May 2010
ISSN: 2070-1721
HTTP Cache-Control Extensions for Stale Content
用于过时内容的HTTP缓存控制扩展
Abstract
摘要
This document defines two independent HTTP Cache-Control extensions that allow control over the use of stale responses by caches.
本文档定义了两个独立的HTTP缓存控制扩展，它们允许控制缓存对过时响应的使用。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5861.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5861.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 2
3. The stale-while-revalidate Cache-Control Extension . . . . . . 2
3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. The stale-if-error Cache-Control Extension . . . . . . . . . . 3
4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. Normative References . . . . . . . . . . . . . . . . . . . . . 5
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 6
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 2
3. The stale-while-revalidate Cache-Control Extension . . . . . . 2
3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. The stale-if-error Cache-Control Extension . . . . . . . . . . 3
4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. Normative References . . . . . . . . . . . . . . . . . . . . . 5
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 6
HTTP [RFC2616] requires that caches "respond to a request with the most up-to-date response held... that is appropriate to the request," although "in carefully considered circumstances" a stale response is allowed to be returned. This document defines two independent Cache-Control extensions that allow for such control, stale-if-error and stale-while-revalidate.
HTTP[RFC2616]要求缓存“响应请求时保留最新的响应……这是适合该请求的”，尽管“在经过仔细考虑的情况下”允许返回过时的响应。本文档定义了两个独立的缓存控制扩展，允许进行此类控制，即错误时失效和重新验证时失效。
The stale-if-error HTTP Cache-Control extension allows a cache to return a stale response when an error -- e.g., a 500 Internal Server Error, a network segment, or DNS failure -- is encountered, rather than returning a "hard" error. This improves availability.
stale if error HTTP缓存控制扩展允许缓存在遇到错误（例如，500内部服务器错误、网段或DNS故障）时返回stale响应，而不是返回“硬”错误。这提高了可用性。
The stale-while-revalidate HTTP Cache-Control extension allows a cache to immediately return a stale response while it revalidates it in the background, thereby hiding latency (both in the network and on the server) from clients.
stale while revalidate HTTP缓存控制扩展允许缓存在后台重新验证时立即返回过时响应，从而对客户端隐藏延迟（在网络和服务器上）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This specification uses the augmented Backus-Naur Form of RFC 2616 [RFC2616], and it includes the delta-seconds rule from that specification.
本规范使用RFC 2616[RFC2616]的扩展巴科斯诺尔形式，并包含该规范中的增量秒规则。
When present in an HTTP response, the stale-while-revalidate Cache-Control extension indicates that caches MAY serve the response in which it appears after it becomes stale, up to the indicated number of seconds.
当出现在HTTP响应中时，stale while revalidate缓存控制扩展指示缓存可以服务于在其变为stale后出现的响应，最长可达指定的秒数。
stale-while-revalidate = "stale-while-revalidate" "=" delta-seconds
过时而重新验证日期=“过时而重新验证日期”“=”增量秒
If a cached response is served stale due to the presence of this extension, the cache SHOULD attempt to revalidate it while still serving stale responses (i.e., without blocking).
如果缓存的响应由于存在此扩展而过时，则缓存应尝试重新验证它，同时仍然提供过时的响应（即，不阻塞）。
Note that "stale" implies that the response will have a non-zero Age header and a warning header, as per HTTP's requirements.
注意，“stale”意味着响应将有一个非零年龄头和一个警告头，这与HTTP的要求一致。
If delta-seconds passes without the cached entity being revalidated, it SHOULD NOT continue to be served stale, absent other information.
如果在缓存实体未重新验证的情况下通过增量秒，则不应在缺少其他信息的情况下继续提供过时的缓存实体。
A response containing:
答复包括：
Cache-Control: max-age=600, stale-while-revalidate=30
Cache-Control: max-age=600, stale-while-revalidate=30
indicates that it is fresh for 600 seconds, and it may continue to be served stale for up to an additional 30 seconds while an asynchronous validation is attempted. If validation is inconclusive, or if there is not traffic that triggers it, after 30 seconds the stale-while-revalidate function will cease to operate, and the cached response will be "truly" stale (i.e., the next request will block and be handled normally).
指示它在600秒内保持新鲜，并且在尝试异步验证时，它可能会在30秒内继续保持不新鲜。如果验证不确定，或者没有触发验证的流量，则30秒后，stale while revalidate函数将停止运行，缓存的响应将“真正”过时（即，下一个请求将被阻塞并正常处理）。
Generally, servers will want to set the combination of max-age and stale-while-revalidate to the longest total potential freshness lifetime that they can tolerate. For example, with both set to 600, the server must be able to tolerate the response being served from cache for up to 20 minutes.
通常情况下，服务器会希望在重新验证时将“最长保存时间”和“过期时间”的组合设置为它们能够容忍的最长的总潜在新鲜度生存期。例如，当两者都设置为600时，服务器必须能够容忍缓存提供的响应长达20分钟。
Since asynchronous validation will only happen if a request occurs after the response has become stale, but before the end of the stale-while-revalidate window, the size of that window and the likelihood of a request during it determines how likely it is that all requests will be served without delay. If the window is too small, or traffic is too sparse, some requests will fall outside of it, and block until the server can validate the cached response.
由于异步验证仅在响应过期之后，但在stale while revalidate窗口结束之前发生请求时才会发生，因此该窗口的大小以及在该窗口期间请求的可能性决定了所有请求不延迟地得到服务的可能性。如果窗口太小，或者通信量太少，一些请求将落在窗口之外，并阻塞，直到服务器能够验证缓存的响应。
The stale-if-error Cache-Control extension indicates that when an error is encountered, a cached stale response MAY be used to satisfy the request, regardless of other freshness information.
stale if error Cache Control扩展指示当遇到错误时，可以使用缓存的stale响应来满足请求，而不管其他新鲜度信息如何。
stale-if-error = "stale-if-error" "=" delta-seconds
陈旧如果错误=“陈旧如果错误”“=”增量秒
When used as a request Cache-Control extension, its scope of application is the request it appears in; when used as a response Cache-Control extension, its scope is any request applicable to the cached response in which it occurs.
当用作请求缓存控制扩展时，其应用范围是它出现在其中的请求；当用作响应缓存控制扩展时，它的作用域是适用于发生它的缓存响应的任何请求。
Its value indicates the upper limit to staleness; when the cached response is more stale than the indicated amount, the cached response SHOULD NOT be used to satisfy the request, absent other information.
其值表示过期的上限；当缓存的响应比指定的数量更过时时，如果没有其他信息，则不应使用缓存的响应来满足请求。
In this context, an error is any situation that would result in a 500, 502, 503, or 504 HTTP response status code being returned.
在此上下文中，错误是任何可能导致返回500、502、503或504 HTTP响应状态代码的情况。
Note that this directive does not affect freshness; stale cached responses that are used SHOULD still be visibly stale when sent (i.e., have a non-zero Age header and a warning header, as per HTTP's requirements).
注意，本指令不影响新鲜度；所使用的过时缓存响应在发送时仍应明显过时（即，根据HTTP的要求，具有非零期限头和警告头）。
A response containing:
答复包括：
HTTP/1.1 200 OK
Cache-Control: max-age=600, stale-if-error=1200
Content-Type: text/plain
HTTP/1.1 200 OK
Cache-Control: max-age=600, stale-if-error=1200
Content-Type: text/plain
success
成功
indicates that it is fresh for 600 seconds, and that it may be used if an error is encountered after becoming stale for an additional 1200 seconds.
指示它在600秒内是新的，如果在超过1200秒后遇到错误，则可以使用它。
Thus, if the cache attempts to validate 900 seconds afterwards and encounters:
因此，如果缓存在900秒后尝试验证，并遇到：
HTTP/1.1 500 Internal Server Error
Content-Type: text/plain
HTTP/1.1 500 Internal Server Error
Content-Type: text/plain
failure
失败
the successful response can be returned instead:
可以返回成功的响应：
HTTP/1.1 200 OK
Cache-Control: max-age=600, stale-if-error=1200
Age: 900
Content-Type: text/plain
HTTP/1.1 200 OK
Cache-Control: max-age=600, stale-if-error=1200
Age: 900
Content-Type: text/plain
success
成功
After the age is greater than 1800 seconds (i.e., it has been stale for 1200 seconds), the cache must write the error message through.
当时间超过1800秒（即，它已过时1200秒）后，缓存必须写入错误消息。
HTTP/1.1 500 Internal Server Error
Content-Type: text/plain
HTTP/1.1 500 Internal Server Error
Content-Type: text/plain
failure
失败
The stale-while-revalidate extension provides origin servers with a mechanism for dictating that stale content should be served from caches under certain circumstances, with the expectation that the cached response will be revalidated in the background. It is suggested that such validation be predicated upon an incoming request, to avoid the possibility of an amplification attack (as can be seen in some other pre-fetching and automatic refresh mechanisms). Cache implementers should keep this in mind when deciding the circumstances under which they will generate a request that is not directly initiated by a user or client.
stale while revalidate扩展为源服务器提供了一种机制，用于指示在某些情况下应从缓存中提供过时内容，并期望缓存响应在后台重新验证。建议在传入请求的基础上进行此类验证，以避免放大攻击的可能性（从其他一些预取和自动刷新机制中可以看出）。缓存实现者在决定在何种情况下生成不是由用户或客户端直接发起的请求时，应该记住这一点。
The stale-if-error provides origin servers and clients a mechanism for dictating that stale content should be served from caches under certain circumstances, and does not pose additional security considerations over those of RFC 2616, which also allows stale content to be served.
stale if错误为源服务器和客户端提供了一种机制，用于指示在某些情况下应从缓存中提供过时内容，并且与RFC 2616相比，它不会带来额外的安全考虑，RFC 2616也允许提供过时内容。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
Thanks to Ben Drees, John Nienart, Henrik Nordstrom, Evan Torrie, and Chris Westin for their suggestions. The author takes all responsibility for errors and omissions.
感谢Ben Drees、John Nienart、Henrik Nordstrom、Evan Torrie和Chris Westin的建议。作者对错误和遗漏承担全部责任。
Author's Address
作者地址
Mark Nottingham Yahoo! Inc.
马克·诺丁汉雅虎！股份有限公司。
EMail: mnot@yahoo-inc.com
URI: http://www.mnot.net/
EMail: mnot@yahoo-inc.com
URI: http://www.mnot.net/