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/