idnits 2.17.00 (12 Aug 2021) /tmp/idnits37564/draft-nottingham-http-stale-if-error-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 192. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 203. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 210. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 216. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 19, 2007) is 5569 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft Yahoo! Inc. 4 Intended status: Informational February 19, 2007 5 Expires: August 23, 2007 7 The stale-if-error HTTP Cache-Control Extension 8 draft-nottingham-http-stale-if-error-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 23, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 The stale-if-error HTTP Cache-Control extension improves availability 42 of some kinds of cached content by allowing servers and clients to 43 instruct caches to use stale responses when certain error conditions 44 are encountered. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 50 3. The stale-if-error Cache-Control Extension . . . . . . . . . . 3 51 4. Response stale-if-error Example . . . . . . . . . . . . . . . . 4 52 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 53 6. Normative References . . . . . . . . . . . . . . . . . . . . . 5 54 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 5 55 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 Intellectual Property and Copyright Statements . . . . . . . . . . 6 58 1. Introduction 60 HTTP [RFC2616] requires that caches "respond to a request with the 61 most up-to-date response held... that is appropriate to the request," 62 although "in carefully controlled circumstances" a stale response is 63 allowed to be returned. 65 Those circumstances are not well-defined. Often, it is useful to 66 return a stale response when an error -- e.g., a 500 Internal Server 67 Error, a network segment, or DNS failure -- is encountered, but 68 caches are understandably reluctant to act without explicit 69 instructions about the appropriate behaviour. 71 The stale-if-error HTTP Cache-Control extension addresses this by 72 allowing origin servers as well as clients to instruct caches to use 73 a stale response under certain conditions, rather than returning a 74 "hard" error, thus improving availability. 76 2. Notational Conventions 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in BCP 14 [RFC2119], as 81 scoped to those conformance targets. 83 This specification uses the augmented Backus-Naur Form of RFC2616 84 [RFC2616], and includes the delta-seconds rule from that 85 specification. 87 3. The stale-if-error Cache-Control Extension 89 The stale-if-error Cache-Control extension indicates that when an 90 error is encountered, a cached stale response MAY be used to satisfy 91 the request, regardless of other freshness information. 93 stale-if-error = "stale-if-error" "=" delta-seconds 95 When used as a request Cache-Control extension, its scope of 96 application is the request it appears in; when used as a response 97 Cache-Control extension, its scope is any request applicable to the 98 cached response it occurs in. 100 Its value indicates the upper limit to staleness; when the cached 101 response is more stale than the indicated amount, the cached response 102 MUST NOT be used to satisfy the request. 104 In this context, an error is any situation which would result in a 105 500, 501, 502, 503 or 504 HTTP response status code to be returned. 106 Future extensions may define additional error conditions. 108 Note that this directive only affects the freshness of a response in 109 an implementation that recognises it; stale cached responses that are 110 used SHOULD still be visibly stale when sent. 112 4. Response stale-if-error Example 114 A response containing: 116 HTTP/1.1 200 OK 117 Cache-Control: max-age=600, stale-if-error=1200 118 Content-Type: text/plain 120 success 122 indicates that it is fresh for 600 seconds, and that it may be used 123 if an error is encountered after becoming stale for an additional 124 1200 seconds. 126 Thus, if the cache attempts to validate 900 seconds afterwards and 127 encounters: 129 HTTP/1.1 500 Internal Server Error 130 Content-Type: text/plain 132 failure 134 the successful response can be returned instead: 136 HTTP/1.1 200 OK 137 Cache-Control: max-age=600, stale-if-error=1200 138 Age: 900 139 Content-Type: text/plain 141 succcess 143 After the age is greater than 1800 seconds (i.e., it has been stale 144 for 1200 seconds), the cache must write the error message through. 146 HTTP/1.1 500 Internal Server Error 147 Content-Type: text/plain 149 failure 151 5. Security Considerations 153 This mechanism does not have any security-specific concerns. 155 6. Normative References 157 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 158 Requirement Levels", BCP 14, RFC 2119, March 1997. 160 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 161 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 162 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 164 Appendix A. Acknowledgements 166 Thanks to John Nienart, Henrik Nordstrom, Evan Torrie, and Chris 167 Westin for their suggestions. The author takes all responsibility 168 for errors and omissions. 170 Author's Address 172 Mark Nottingham 173 Yahoo! Inc. 175 Email: mnot@yahoo-inc.com 176 URI: http://www.mnot.net/ 178 Full Copyright Statement 180 Copyright (C) The IETF Trust (2007). 182 This document is subject to the rights, licenses and restrictions 183 contained in BCP 78, and except as set forth therein, the authors 184 retain all their rights. 186 This document and the information contained herein are provided on an 187 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 188 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 189 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 190 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 191 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 192 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 194 Intellectual Property 196 The IETF takes no position regarding the validity or scope of any 197 Intellectual Property Rights or other rights that might be claimed to 198 pertain to the implementation or use of the technology described in 199 this document or the extent to which any license under such rights 200 might or might not be available; nor does it represent that it has 201 made any independent effort to identify any such rights. Information 202 on the procedures with respect to rights in RFC documents can be 203 found in BCP 78 and BCP 79. 205 Copies of IPR disclosures made to the IETF Secretariat and any 206 assurances of licenses to be made available, or the result of an 207 attempt made to obtain a general license or permission for the use of 208 such proprietary rights by implementers or users of this 209 specification can be obtained from the IETF on-line IPR repository at 210 http://www.ietf.org/ipr. 212 The IETF invites any interested party to bring to its attention any 213 copyrights, patents or patent applications, or other proprietary 214 rights that may cover technology that may be required to implement 215 this standard. Please address the information to the IETF at 216 ietf-ipr@ietf.org. 218 Acknowledgment 220 Funding for the RFC Editor function is provided by the IETF 221 Administrative Support Activity (IASA).