idnits 2.17.1 draft-nottingham-linked-cache-inv-04.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 (December 21, 2012) is 4145 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 December 21, 2012 5 Expires: June 24, 2013 7 Linked Cache Invalidation 8 draft-nottingham-linked-cache-inv-04 10 Abstract 12 This memo defines two new link types that indicate relationships 13 between resources in terms of cache invalidation, along with a HTTP 14 cache-control extension that takes advantage of those relationships 15 to use them to extend response freshness. Collectively, this is 16 referred to as Linked Cache Invalidation (LCI). 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on June 24, 2013. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 5 52 3. The 'invalidates' Link Relation Type . . . . . . . . . . . . . 5 53 4. The 'inv-by' Link Relation Type . . . . . . . . . . . . . . . . 5 54 5. The 'inv-maxage' Response Cache-Control Extension . . . . . . . 6 55 5.1. inv-maxage Syntax . . . . . . . . . . . . . . . . . . . . . 6 56 5.2. inv-maxage Semantics . . . . . . . . . . . . . . . . . . . 6 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 58 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 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 an unsafe request (e.g., POST, PUT or DELETE) is made to 69 its URI. HTTP also provides for such a state-changing request to 70 invalidate related resources (using the Location and Content-Location 71 headers in the response), but this is of limited utility, because 72 those headers have defined semantics, and can only occur once each. 74 Because of this, it is not practical to make a response that depends 75 on the state of another resource cacheable. For example, an update 76 to a blog entry might change several different resources, such as the 77 user's summary page, the blog's "front" page, the blog's Atom feed, 78 and of course the blog entry itself. If any of these resources is 79 made cacheable, it will not reflect those changes, causing confusion 80 if the user tries to verify that their changes have been correctly 81 applied. 83 This memo introduces new link relation types [RFC5988] that allow 84 more fine-grained relationships between resources to be defined, so 85 that caches can invalidate all related representations when the state 86 of one changes. It also introduces a cache-control response 87 extension, so that responses using the relations can be cached by 88 implementations that understand these relations. 90 1.1. Example 92 Taking the blog use case described above, imagine that we have the 93 following related resources: 95 o http://example.com/blog/2012/05/04/hi [the blog entry] 96 o http://example.com/blog/2012/05/04/hi/comments [full comments for 97 the entry] 98 o http://example.com/blog/ {the blog "home"} 99 o http://example.com/users/bob/ [the user page, listing his entries] 101 When someone comments on Bob's blog entry, they might send a request 102 like this: 104 POST /cgi-bin/blog.cgi HTTP/1.1 105 Host: example.com 106 Content-Type: application/x-www-form-urlencoded 107 Content-Length: 7890 109 [...] 111 When the comment is successful, it's typical to redirect the client 112 back to the original blog page, with a response like this: 114 HTTP/1.1 302 Moved Temporarily 115 Location: http://example.com/blog/2012/05/04/hi 116 Content-Length: 0 118 Which would invalidate the blog entry URI, as per HTTP's normal 119 operation. 121 To invalidate the full comments page for the entry, the relationship 122 can be described in that page's response headers: 124 HTTP/1.1 200 OK 125 Content-Type: text/html 126 Content-Length: 5555 127 Link: ; rel="inv-by" 128 Cache-Control: no-cache, inv-maxage=600 130 [...] 132 This declares that whenever the entry page (the target of the link 133 header) changes, this response (the full comments page) changes as 134 well; it's invalidated by the link target. 136 Note that the full comments page also carries a Cache-Control header 137 that instructs "normal" caches not to reuse this response, but allows 138 those caches that are aware of LCI to consider it fresh for ten 139 minutes. 141 To invalidate the blog home page and user page, it's impractical to 142 list all of the resources that might change if a new entry is posted; 143 not only are there many of them, but their URLs might not be known 144 when the pages are cached. To address this, the POST response itself 145 (i.e., when the comment is made) can nominate resources to 146 invalidate, using the 'invalidates' relation, making that response: 148 HTTP/1.1 302 Moved Temporarily 149 Location: http://example.com/blog/2012/05/04/hi 150 Link: ; rel="invalidates", 151 ; rel="invalidates" 152 Content-Length: 0 154 Depending on how important it is to see updates on the home page and 155 user page, those responses can either allow caching regardless of 156 support for LCI, like this: 158 Cache-Control: max-age=300 159 ... or they can only allow caching by LCI-aware caches, like this: 161 Cache-Control: no-cache, inv-maxage=300 163 Together, these techniques can be used to invalidate a variety of 164 related responses. 166 It is important to note that the invalidations are only effective in 167 the caches that the client's request stream travels through. This 168 means other caches will continue to serve the "old" content until the 169 invalidation event is propagated to them (see below) or the cached 170 responses become stale. 172 When multiple caches are close together, the HyperText Caching 173 Protocol (HTCP) [RFC2756] can be used to propagate invalidation 174 events between them. 176 2. Notational Conventions 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in RFC 2119 [RFC2119]. 182 This document uses the Augmented Backus-Naur Form (ABNF) notation of 183 [RFC2616], and explicitly includes the following rules from it: 184 delta-seconds. 186 3. The 'invalidates' Link Relation Type 188 The 'invalidates' link relation type allows a response that signifies 189 a state change on the server to indicate one or more associated URIs 190 whose states have also changed. 192 o Relation name: invalidates 193 o Description: Indicates that when the link context changes, the 194 link target also has changed. 195 o Reference: [this document] 196 o Notes: 198 4. The 'inv-by' Link Relation Type 200 The 'inv-by' link relation type allows a response to nominate one or 201 more other resources that affect the state of the resource it's 202 associated with. That is, when one of the nominated resources 203 changes, it also changes the state of this response's resource. 205 o Relation name: inv-by 206 o Description: Indicates that when the link target changes, the 207 link's context has also changed. 208 o Reference: [this document] 209 o Notes: 211 5. The 'inv-maxage' Response Cache-Control Extension 213 When present, the 'inv-maxage' cache-control extension indicates the 214 number of seconds that caches who implement Linked Cache invalidation 215 can consider responses fresh for, provided they are not invalidated. 217 5.1. inv-maxage Syntax 219 The inv-maxage cache-control extension is parameterised with a 220 numeric argument: 222 "inv-maxage" "=" ( delta-seconds | ( <"> delta-seconds <"> ) ) 224 Note that the argument MAY occur in either token or quoted-string 225 form. 227 If the argument is missing or otherwise does not conform to the BNF 228 rule, it is invalid and MUST be ignored by caches. 230 If the directive appears more than once in a response, each instance 231 is invalid and MUST be ignored by caches. 233 5.2. inv-maxage Semantics 235 HTTP caches MAY, if they fully implement this specification, 236 disregard the HTTP response cache-control directives 'no-cache', 237 'max-age' and 's-maxage' when a valid 'inv-maxage' cache-control 238 directive is present in a response, using its value as a replacement 239 for max-age. 241 HTTP caches using inv-maxage to calculate freshness MUST invalidate 242 all stored responses whose request-URIs (after normalisation) are the 243 target of a 'invalidates' link relation contained in a successful 244 response to a state-changing request, provided that they are allowed. 246 HTTP caches using inv-maxage to calculate freshness MUST invalidate 247 all stored responses containing a 'inv-by' link relation whose target 248 is the current request-URI (after normalisation) upon receipt of a 249 successful response to a state-changing request. 251 Likewise, HTTP caches using inv-maxage to calculate freshness MUST 252 invalidate all stored responses containing a 'inv-by' link relation 253 whose target is the content of either the Location or Content- 254 Location response headers (after normalisation) upon receipt of a 255 successful response to a state-changing request. 257 Here, a response is considered to "contain" a link relation if it is 258 carried in the Link HTTP header [RFC5988]. I.e., it is not necessary 259 to look at the response body. 261 "Invalidate" means that the cache will either remove all stored 262 responses related to the effective request URI, or will mark these as 263 "invalid" and in need of a mandatory validation before they can be 264 returned in response to a subsequent request. 266 A "successful" response is one with a 2xx or redirecting 3xx (e.g., 267 301, 302, 303, 307) status code. 269 A "state-changing" request is one with an unsafe method (e.g., POST, 270 PUT, DELETE, PATCH), or one that is not known to be safe. 272 In this context, "normalisation" means, in the case of a relative 273 request-URI, that it is absolutised using the value of the Host 274 request header and the appropriate protocol scheme. 276 Finally, an invalidation based upon "invalidates" is "allowed" if the 277 host part of the request-URI (if absolute) or Host request header (if 278 the request-URI is relative) matches the host part of the target URI. 279 This prevents some types of denial-of-service attacks. 281 Implementations SHOULD effect invalidations when they become aware of 282 changes through other means; e.g., HTCP [RFC2756] CLR messages, upon 283 invalidations caused by other links (i.e., chained "cascades" of 284 linked invalidations), or when a changed response is seen (such as 285 when HTTP validation is unsuccessful). 287 6. Security Considerations 289 Linked Cache Invalidation does not guarantee that invalidations will 290 be effected; e.g., they can be lost due to network issues or cache 291 downtime. Furthermore, it does not guarantee that all caches that 292 understand LCI will be made aware of invalidations that happen, 293 because of how they originate. 295 Therefore, care should be taken that LCI invalidations are not relied 296 upon (e.g., to purge sensitive content). 298 Furthermore, while some care is taken to avoid denial-of-service 299 attacks through invalidation, cache efficiency may still be impaired 300 under certain circumstances (e.g., arranging for one request to 301 invalidate a large number of responses), leading to a reduction in 302 service quality. 304 7. IANA Considerations 306 This document registers two entries in the Link Relation Type 307 Registry; see Section 3 and Section 4. 309 It also registers a HTTP Cache Directive, "inv-maxage"; see 310 Section 5. 312 8. References 314 8.1. Normative References 316 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 317 Requirement Levels", BCP 14, RFC 2119, March 1997. 319 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 320 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 321 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 323 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 325 8.2. Informative References 327 [RFC2756] Vixie, P. and D. Wessels, "Hyper Text Caching Protocol 328 (HTCP/0.0)", RFC 2756, January 2000. 330 Appendix A. Acknowledgements 332 Thanks to Michael Hausenblas for his input. 334 Authors' Addresses 336 Mark Nottingham 338 Email: mnot@mnot.net 339 URI: http://www.mnot.net/ 340 Mike Kelly 342 Email: mike@stateless.co 343 URI: http://stateless.co/