idnits 2.17.00 (12 Aug 2021) /tmp/idnits54686/draft-nottingham-linked-cache-inv-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 25, 2011) is 3829 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) ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft M. Kelly 4 Intended status: Informational November 25, 2011 5 Expires: May 28, 2012 7 Linked Cache Invalidation 8 draft-nottingham-linked-cache-inv-01 10 Abstract 12 This memo defines Web link types that invalidate HTTP caches, along 13 with an HTTP cache-control extension that allows caches that 14 understand those link types to use responses containing them. 15 Together, these mechanisms offer a way to avoid use of a response 16 that has become stale due to another request that changes server-side 17 state. Collectively, this is referred to as Linked Cache 18 Invalidation (LCI). 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 28, 2012. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 5 54 3. The 'invalidates' link relation type . . . . . . . . . . . . . 5 55 4. The 'inv-by' link relation type . . . . . . . . . . . . . . . . 6 56 5. The 'inv-maxage' response cache-control extension . . . . . . . 6 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 58 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 59 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 61 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 62 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 8 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 65 1. Introduction 67 In normal operation, a HTTP [RFC2616] cache will invalidate a stored 68 response if a state-changing request (e.g., POST, PUT or DELETE) is 69 made for that URI. HTTP also provides for such a state-changing 70 request to invalidate related resources (using the Location and 71 Content-Location headers in the response), but this is of limited 72 utility, because those headers have defined semantics, and can only 73 occur once each. 75 Because of this, it is not practical to make a response that depends 76 on the state of another resource cacheable. For example, an update 77 to a blog entry might change several different resources, such as the 78 user's summary page, the blog's "front" page, the blog's Atom feed, 79 and of course the blog entry itself. If any of these resources is 80 made cacheable, it will not reflect those changes, causing confusion 81 if the user tries to verify that their changes have been correctly 82 applied. 84 This memo introduces new Web link relation types [RFC5988] that allow 85 more fine-grained relationships between resources to be defined, so 86 that caches can invalidate all related resources when the state of 87 one changes. It also introduces a cache-control response extension, 88 so that responses using the relations can be cached by 89 implementations that understand these relations. 91 1.1. Example 93 Taking the blog use case described above, imagine that we have the 94 following related resources: 96 o http://example.com/blog/2011/05/04/hi {the blog entry} 97 o http://example.com/blog/2011/05/04/hi/comments {full comments for 98 the entry} 99 o http://example.com/blog/ {the blog "home"} 100 o http://example.com/users/bob/ {the user page, listing his entries} 102 When someone comments on Bob's blog entry, they might send a request 103 like this: 105 POST /cgi-bin/blog.cgi HTTP/1.1 106 Host: example.com 107 Content-Type: application/x-www-form-urlencoded 108 Content-Length: 7890 110 [...] 112 This request (if successful) should have the effect of invalidating 113 the related resources listed above. 115 If the comment is successful, it's typical to redirect the client 116 back to the original blog page, with a response like this: 118 HTTP/1.1 302 Moved Temporarily 119 Location: http://example.com/blog/2011/05/04/hi 120 Content-Length: 0 122 Which would invalidate the blog entry URI, as per HTTP's normal 123 operation. 125 To invalidate the full comments page for the entry, the relationship 126 can be described in that page's response headers: 128 HTTP/1.1 200 OK 129 Content-Type: text/html 130 Content-Length: 5555 131 Link: ; rel="inv-by" 132 Cache-Control: no-cache, inv-maxage=600 134 [...] 136 This declares that whenever the entry page (the target of the link 137 header) changes, this response (the full comments page) changes as 138 well; it's invalidated by the link target. 140 Note that the full comments page also carries a Cache-Control header 141 that instructs "normal" caches not to reuse this response, but allows 142 those caches that are aware of LCI to consider it fresh for ten 143 minutes. 145 To invalidate the blog home page and user page, it's impractical to 146 list all of the resources that might change if a new entry is posted; 147 not only are there many of them, but their URLs might not be known 148 when the pages are cached. To address this, the POST response itself 149 can nominate resources to invalidate, using the 'invalidates' 150 relation, making that response: 152 HTTP/1.1 302 Moved Temporarily 153 Location: http://example.com/blog/2011/05/04/hi 154 Link: ; rel="invalidates", 155 ; rel="invalidates" 156 Content-Length: 0 158 Depending on how important it is to see updates on the home page and 159 user page, those responses can either allow caching regardless of 160 support for LCI, like this: 162 Cache-Control: max-age=300 164 ... or they can only allow caching by LCI-aware caches, like this: 166 Cache-Control: no-cache, inv-maxage=300 168 Together, these techniques can be used to invalidate a variety of 169 related responses. 171 It is important to note that the invalidations are only effective in 172 the caches that the client's request stream travels through. 173 Typically, this means that the client making the changes (e.g., the 174 blog update above) will see the effects immediately, while other 175 users whose requests travel through different caches will only see 176 the changes once the content becomes stale (if it is cached). 178 This makes Linked Cache Invalidation useful in a number of cases, but 179 not all; when it's important that changes be propagated quickly, the 180 freshness lifetime of cached responses can be reduced, but there will 181 still be lag. 183 When multiple caches are close together, the HyperText Caching 184 Protocol (HTCP) [RFC2756] can be used to propagate invalidation 185 events between caches, reducing (but not eliminating) these effects. 187 2. Notational Conventions 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 191 document are to be interpreted as described in RFC 2119 [RFC2119]. 193 This document uses the Augmented Backus-Naur Form (ABNF) notation of 194 [RFC2616], and explicitly includes the following rules from it: 195 delta-seconds. 197 3. The 'invalidates' link relation type 199 The 'invalidates' link relation type allows a response that is an 200 signifies a state change on the server to indicate one or more 201 associated URIs whose states have also changed. 203 o Relation name: invalidates 204 o Description: Indicates that when the link context changes, the 205 link target also has changed. 206 o Reference: [this document] 207 o Notes: 209 4. The 'inv-by' link relation type 211 The 'inv-by' link relation type allows a response to nominate one or 212 more other resources that affect the state of the resource it's 213 associated with. That is, when one of the nominated resources 214 changes, it also changes the state of this response's resource. 216 o Relation name: inv-by 217 o Description: Indicates that when the link target changes, the 218 link's context has also changed. 219 o Reference: [this document] 220 o Notes: 222 5. The 'inv-maxage' response cache-control extension 224 When present, the 'inv-maxage' cache-control extension indicates the 225 number of seconds that caches who implement Linked Cache invalidation 226 can consider responses fresh for. 228 "inv-maxage" "=" delta-seconds 230 HTTP caches MAY, if they fully implement this specification, 231 disregard the HTTP response cache-control directives 'no-cache', 232 'max-age' and 's-maxage' and use the value of inv-maxage as a 233 replacement for max-age. 235 HTTP caches using inv-maxage to calculate freshness MUST invalidate 236 all stored responses whose request-URIs (after normalisation) are 237 indicated by the 'invalidates' link relation type contained in a 238 successful response to a state-changing request, provided that they 239 are allowed. 241 HTTP caches using inv-maxage to calculate freshness MUST invalidate 242 all stored responses containing the 'inv-by' relation that indicates 243 the current request-URI (after normalisation) upon receipt of a 244 successful response to a state-changing request. 246 Here, a response is considered to "contain" a link relation if it is 247 carried in the Link HTTP header [RFC5988]. I.e., it is not necessary 248 to look at the response body. 250 "Invalidate" means that the cache will either remove all stored 251 responses related to the effective request URI, or will mark these as 252 "invalid" and in need of a mandatory validation before they can be 253 returned in response to a subsequent request. 255 A "successful" response is one with a 2xx or redirecting 3xx (e.g., 256 301, 302, 303, 307) status code. 258 A "state-changing" request is one with an unsafe method (e.g., POST, 259 PUT, DELETE, PATCH), or one that is not known to be safe. 261 In this context, "normalisation" means, in the case of a relative 262 request-URI, that it is absolutised using the value of the Host 263 request header and the appropriate protocol scheme. 265 Finally, an invalidation based upon "invalidates" is "allowed" if the 266 host part of the request-URI (if absolute) or Host request header (if 267 the request-URI is relative) matches the host part of the target URI. 268 This prevents some types of denial-of-service attacks. 270 Implementations SHOULD effect invalidations when they become aware of 271 changes through other means; e.g., HTCP [RFC2756] CLR messages, upon 272 invalidations caused by other links (i.e., chained "cascades" of 273 linked invalidations), or when a changed response is seen (such as 274 when HTTP validation is unsuccessful). 276 6. Security Considerations 278 Linked Cache Invalidation does not guarantee that invalidations will 279 be effected; e.g., they can be lost due to network issues or cache 280 downtime. Furthermore, it does not guarantee that all caches that 281 understand LCI will be made aware of invalidations that happen, 282 because of how they originate. 284 Therefore, care should be taken that LCI invalidations are not relied 285 upon (e.g., to purge sensitive content). 287 Furthermore, while some care is taken to avoid denial-of-service 288 attacks through invalidation, cache efficiency may still be impaired 289 under certain circumstances (e.g., arranging for one request to 290 invalidate a large number of responses), leading to a reduction in 291 service quality. 293 7. IANA Considerations 295 This document registers two entries in the Link Relation Type 296 Registry; see Section 3 and Section 4. 298 8. References 300 8.1. Normative References 302 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 303 Requirement Levels", BCP 14, RFC 2119, March 1997. 305 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 306 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 307 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 309 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 311 8.2. Informative References 313 [RFC2756] Vixie, P. and D. Wessels, "Hyper Text Caching Protocol 314 (HTCP/0.0)", RFC 2756, January 2000. 316 Appendix A. Acknowledgements 318 Thanks to Michael Hausenblas for his input. 320 The authors take all responsibility for errors and omissions. 322 Authors' Addresses 324 Mark Nottingham 326 Email: mnot@mnot.net 327 URI: http://www.mnot.net/ 329 Mike Kelly 331 Email: mike@stateless.co 332 URI: http://stateless.co/