idnits 2.17.00 (12 Aug 2021) /tmp/idnits55247/draft-nottingham-linked-cache-inv-02.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 (June 1, 2012) is 3640 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 June 1, 2012 5 Expires: December 3, 2012 7 Linked Cache Invalidation 8 draft-nottingham-linked-cache-inv-02 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 December 3, 2012. 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 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 56 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 57 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 59 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 60 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 8 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 63 1. Introduction 65 In normal operation, a HTTP [RFC2616] cache will invalidate a stored 66 response if an unsafe request (e.g., POST, PUT or DELETE) is made to 67 its URI. HTTP also provides for such a state-changing request to 68 invalidate related resources (using the Location and Content-Location 69 headers in the response), but this is of limited utility, because 70 those headers have defined semantics, and can only occur once each. 72 Because of this, it is not practical to make a response that depends 73 on the state of another resource cacheable. For example, an update 74 to a blog entry might change several different resources, such as the 75 user's summary page, the blog's "front" page, the blog's Atom feed, 76 and of course the blog entry itself. If any of these resources is 77 made cacheable, it will not reflect those changes, causing confusion 78 if the user tries to verify that their changes have been correctly 79 applied. 81 This memo introduces new link relation types [RFC5988] that allow 82 more fine-grained relationships between resources to be defined, so 83 that caches can invalidate all related representations when the state 84 of one changes. It also introduces a cache-control response 85 extension, so that responses using the relations can be cached by 86 implementations that understand these relations. 88 1.1. Example 90 Taking the blog use case described above, imagine that we have the 91 following related resources: 93 o http://example.com/blog/2012/05/04/hi [the blog entry] 94 o http://example.com/blog/2012/05/04/hi/comments [full comments for 95 the entry] 96 o http://example.com/blog/ {the blog "home"} 97 o http://example.com/users/bob/ [the user page, listing his entries] 99 When someone comments on Bob's blog entry, they might send a request 100 like this: 102 POST /cgi-bin/blog.cgi HTTP/1.1 103 Host: example.com 104 Content-Type: application/x-www-form-urlencoded 105 Content-Length: 7890 107 [...] 109 When the comment is successful, it's typical to redirect the client 110 back to the original blog page, with a response like this: 112 HTTP/1.1 302 Moved Temporarily 113 Location: http://example.com/blog/2012/05/04/hi 114 Content-Length: 0 116 Which would invalidate the blog entry URI, as per HTTP's normal 117 operation. 119 To invalidate the full comments page for the entry, the relationship 120 can be described in that page's response headers: 122 HTTP/1.1 200 OK 123 Content-Type: text/html 124 Content-Length: 5555 125 Link: ; rel="inv-by" 126 Cache-Control: no-cache, inv-maxage=600 128 [...] 130 This declares that whenever the entry page (the target of the link 131 header) changes, this response (the full comments page) changes as 132 well; it's invalidated by the link target. 134 Note that the full comments page also carries a Cache-Control header 135 that instructs "normal" caches not to reuse this response, but allows 136 those caches that are aware of LCI to consider it fresh for ten 137 minutes. 139 To invalidate the blog home page and user page, it's impractical to 140 list all of the resources that might change if a new entry is posted; 141 not only are there many of them, but their URLs might not be known 142 when the pages are cached. To address this, the POST response itself 143 (i.e., when the comment is made) can nominate resources to 144 invalidate, using the 'invalidates' relation, making that response: 146 HTTP/1.1 302 Moved Temporarily 147 Location: http://example.com/blog/2012/05/04/hi 148 Link: ; rel="invalidates", 149 ; rel="invalidates" 150 Content-Length: 0 152 Depending on how important it is to see updates on the home page and 153 user page, those responses can either allow caching regardless of 154 support for LCI, like this: 156 Cache-Control: max-age=300 157 ... or they can only allow caching by LCI-aware caches, like this: 159 Cache-Control: no-cache, inv-maxage=300 161 Together, these techniques can be used to invalidate a variety of 162 related responses. 164 It is important to note that the invalidations are only effective in 165 the caches that the client's request stream travels through. This 166 means other caches will continue to serve the "old" content until the 167 invalidation event is propagated to them (see below) or the cached 168 responses become stale. 170 When multiple caches are close together, the HyperText Caching 171 Protocol (HTCP) [RFC2756] can be used to propagate invalidation 172 events between them. 174 2. Notational Conventions 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in RFC 2119 [RFC2119]. 180 This document uses the Augmented Backus-Naur Form (ABNF) notation of 181 [RFC2616], and explicitly includes the following rules from it: 182 delta-seconds. 184 3. The 'invalidates' link relation type 186 The 'invalidates' link relation type allows a response that signifies 187 a state change on the server to indicate one or more associated URIs 188 whose states have also changed. 190 o Relation name: invalidates 191 o Description: Indicates that when the link context changes, the 192 link target also has changed. 193 o Reference: [this document] 194 o Notes: 196 4. The 'inv-by' link relation type 198 The 'inv-by' link relation type allows a response to nominate one or 199 more other resources that affect the state of the resource it's 200 associated with. That is, when one of the nominated resources 201 changes, it also changes the state of this response's resource. 203 o Relation name: inv-by 204 o Description: Indicates that when the link target changes, the 205 link's context has also changed. 206 o Reference: [this document] 207 o Notes: 209 5. The 'inv-maxage' response cache-control extension 211 When present, the 'inv-maxage' cache-control extension indicates the 212 number of seconds that caches who implement Linked Cache invalidation 213 can consider responses fresh for, provided they are not invalidated. 215 "inv-maxage" "=" delta-seconds 217 HTTP caches MAY, if they fully implement this specification, 218 disregard the HTTP response cache-control directives 'no-cache', 219 'max-age' and 's-maxage' and use the value of inv-maxage as a 220 replacement for max-age. 222 HTTP caches using inv-maxage to calculate freshness MUST invalidate 223 all stored responses whose request-URIs (after normalisation) are the 224 target of a 'invalidates' link relation contained in a successful 225 response to a state-changing request, provided that they are allowed. 227 HTTP caches using inv-maxage to calculate freshness MUST invalidate 228 all stored responses containing a 'inv-by' link relation whose target 229 is the current request-URI (after normalisation) upon receipt of a 230 successful response to a state-changing request. 232 Likewise, HTTP caches using inv-maxage to calculate freshness MUST 233 invalidate all stored responses containing a 'inv-by' link relation 234 whose target is the content of either the Location or Content- 235 Location response headers (after normalisation) upon receipt of a 236 successful response to a state-changing request. 238 Here, a response is considered to "contain" a link relation if it is 239 carried in the Link HTTP header [RFC5988]. I.e., it is not necessary 240 to look at the response body. 242 "Invalidate" means that the cache will either remove all stored 243 responses related to the effective request URI, or will mark these as 244 "invalid" and in need of a mandatory validation before they can be 245 returned in response to a subsequent request. 247 A "successful" response is one with a 2xx or redirecting 3xx (e.g., 248 301, 302, 303, 307) status code. 250 A "state-changing" request is one with an unsafe method (e.g., POST, 251 PUT, DELETE, PATCH), or one that is not known to be safe. 253 In this context, "normalisation" means, in the case of a relative 254 request-URI, that it is absolutised using the value of the Host 255 request header and the appropriate protocol scheme. 257 Finally, an invalidation based upon "invalidates" is "allowed" if the 258 host part of the request-URI (if absolute) or Host request header (if 259 the request-URI is relative) matches the host part of the target URI. 260 This prevents some types of denial-of-service attacks. 262 Implementations SHOULD effect invalidations when they become aware of 263 changes through other means; e.g., HTCP [RFC2756] CLR messages, upon 264 invalidations caused by other links (i.e., chained "cascades" of 265 linked invalidations), or when a changed response is seen (such as 266 when HTTP validation is unsuccessful). 268 6. Security Considerations 270 Linked Cache Invalidation does not guarantee that invalidations will 271 be effected; e.g., they can be lost due to network issues or cache 272 downtime. Furthermore, it does not guarantee that all caches that 273 understand LCI will be made aware of invalidations that happen, 274 because of how they originate. 276 Therefore, care should be taken that LCI invalidations are not relied 277 upon (e.g., to purge sensitive content). 279 Furthermore, while some care is taken to avoid denial-of-service 280 attacks through invalidation, cache efficiency may still be impaired 281 under certain circumstances (e.g., arranging for one request to 282 invalidate a large number of responses), leading to a reduction in 283 service quality. 285 7. IANA Considerations 287 This document registers two entries in the Link Relation Type 288 Registry; see Section 3 and Section 4. 290 8. References 291 8.1. Normative References 293 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 294 Requirement Levels", BCP 14, RFC 2119, March 1997. 296 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 297 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 298 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 300 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 302 8.2. Informative References 304 [RFC2756] Vixie, P. and D. Wessels, "Hyper Text Caching Protocol 305 (HTCP/0.0)", RFC 2756, January 2000. 307 Appendix A. Acknowledgements 309 Thanks to Michael Hausenblas for his input. 311 Authors' Addresses 313 Mark Nottingham 315 Email: mnot@mnot.net 316 URI: http://www.mnot.net/ 318 Mike Kelly 320 Email: mike@stateless.co 321 URI: http://stateless.co/