idnits 2.17.1 draft-nottingham-http-cache-channels-01.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 520. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 531. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 538. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 544. 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 (October 12, 2007) is 6040 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2616 (ref. '1') (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 October 12, 2007 5 Expires: April 14, 2008 7 HTTP Cache Channels 8 draft-nottingham-http-cache-channels-01 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 April 14, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This specification defines "cache channels" to propagate out-of-band 42 events from HTTP origin servers (or their delegates) to subscribing 43 caches. It also defines an event payload that gives finer-grained 44 control over cache freshness. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 50 3. Cache Channels . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3.1. Channel Subscription . . . . . . . . . . . . . . . . . . . 5 52 3.2. Event Application . . . . . . . . . . . . . . . . . . . . 5 53 3.3. Atom Cache Channels . . . . . . . . . . . . . . . . . . . 6 54 3.3.1. The 'cc:precision' Feed Extension . . . . . . . . . . 7 55 3.3.2. The 'cc:lifetime' Feed Extension . . . . . . . . . . . 7 56 3.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 8 57 4. Manging Freshness with Cache Channels . . . . . . . . . . . . 8 58 4.1. The 'channel-maxage' Response Cache-Control Extension . . 9 59 4.2. The 'stale' Cache Channel Event . . . . . . . . . . . . . 9 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 61 6. Normative References . . . . . . . . . . . . . . . . . . . . . 10 62 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 63 Appendix B. Operational Considerations . . . . . . . . . . . . . 11 64 Appendix C. Implementation Notes . . . . . . . . . . . . . . . . 11 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 Intellectual Property and Copyright Statements . . . . . . . . . . 13 68 1. Introduction 70 This specification defines "cache channels" that propagate out-of- 71 band events from HTTP [1] origin servers (or their delegates) to 72 subscribing caches. It also defines an event payload that gives 73 finer-grained control over cache freshness. 75 Typically, a cache will discover channels of interest by examining 76 Cache-Control response headers for the "channel" extension; when 77 present, it indicates that the response is associated with that 78 channel. Upon subscription, caches will receive all events in that 79 channel. 81 To allow use of a variety of underlying protocols, the process of 82 subscription and the means of propagating events in the channel are 83 specific to the transport in use. This specification does define one 84 such channel transport, using the Atom Syndication Format [2]. 86 Likewise, channels may be used to convey a variety of events from 87 origin servers to caches. This specification defines one such 88 payload, the 'stale' event, that affords finer-grained control over 89 freshness than available in HTTP alone. 91 Together, cache channels and the stale event enable an origin server 92 to maintain control over the content of a set of caches while 93 increasing their efficiency. For example, "reverse proxies" are 94 often used to accelerate HTTP servers by caching their content; cache 95 channels and stale events can be used to more closely control their 96 behaviour. 98 This use of cache channels is similar to an invalidation protocol, 99 except that the protocol described here operates by extending cached 100 responses' freshness lifetime, rather than invalidating them. This 101 preserves the semantics of the HTTP caching model and assures that 102 the failure modes are safe. 104 Additionally, the 'group' functionality of cache channels enables 105 stale events to apply to several cached responses, thereby offering 106 control over freshness of responses whose request-URIs may not be 107 known. For example, a HTTP search interface may have given several 108 responses containing the same information; if they are grouped 109 together, it is possible to force them to become stale without 110 knowing their request-URIs. 112 2. Notational Conventions 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in BCP 14 [3], as scoped 117 to those conformance targets. 119 This specification uses the augmented Backus-Naur Form of RFC2616 120 [1], and includes the delta-seconds rule from that specification, and 121 the absolute-URI rule from RFC3986 [4]. 123 Elements defined by this specification use the XML namespace [5] URI 124 "http://purl.org/syndication/cache-channel". In this specification, 125 that URI is assumed to be bound to the prefix "cc". 127 3. Cache Channels 129 A cache channel is an out-of-band path from an origin server (or its 130 delegate) to one or more interested caches. It is identified by a 131 URI [4]. 133 A channel contains events, each of which may be associated with one 134 or more URIs. The payload of each event is applied to its associated 135 URIs when it is received. 137 Typically, a cache channel will convey events applicable to a variety 138 of URIs in an administrative domain; for example, it might carry all 139 events that apply to a single origin server, or a group of origin 140 servers. 142 From the perspective of a cache, a channel has several interesting 143 states; 145 o unsubscribed: The channel is not being monitored. 146 o connected: The channel is being monitored, and events are able to 147 be propagated. 148 o disconnected: The channel is being monitored, but events are not 149 able to be propagated. 151 Channels MUST make the events that they contain available for an 152 advertised amount of time, known as the lifetime of the channel. 153 This allows clients that have been disconnected to re-synchronise 154 themselves with the contents of the channel upon becoming re- 155 connected. 157 Channels SHOULD also advertise the desired maximum propagation delay 158 for events, known as their precision. 160 Two general processes facilitate the operation of cache channels; 161 subscription and event application. 163 3.1. Channel Subscription 165 Channels are advertised using the "channel" HTTP response cache- 166 control extension. 168 channel-extension = "channel" "=" <"> channel-URI <"> 169 channel-URI = absolute-URI 171 A recipient of this cache-control extension can subscribe to the 172 channel-URI when interested in receiving events associated with the 173 response. 175 The specific mechanism for subscription is determined by the channel- 176 URI's scheme and other factors (e.g., the media type of the 177 representation obtained by dereferencing that URI). 179 If a subsequent response has a different channel-URI, or no channel- 180 URI, and there are no other responses associated with the same 181 channel-URI, a subscriber MAY unsubscribe from the channel. 183 A response MUST NOT have more than one channel-extension. 185 For example, 187 Cache-Control: max-age=300, channel="http://example.org/channels/a" 189 3.2. Event Application 191 An event carries one or more event-URIs, which are used to determine 192 what cached responses the event applies to. This includes responses 193 whose request-URI matches an event-URI, and those with a group-URI 194 matching an event-URI. 196 Responses can be associated with a group-URI using the "group" 197 response Cache-Control extension; 199 group-extension = "group" "=" <"> group-URI <"> 200 group-URI = absolute-URI 202 A response MAY have any number of group-extensions. 204 For example, a response carrying the following Cache-Control header; 206 Cache-Control: max=age=600, channel="http://example.com/channels/a", 207 group="urn:uuid:30A909D9-BC7A-4257-BE09-6F781AD6471F" 209 will not only have those events which match the response's request- 210 URI applied, but also events who match the URI 211 "urn:uuid:30A909D9-BC7A-4257-BE09-6F781AD6471F". 213 This mechanism allows application of events to arbitrary sets of 214 responses using a synthetic identifier. 216 For example, if "http://example.com/", "http://example.com/top.html" 217 and "http://example.com/index.html" are all associated with the group 218 identified by "urn:uuid:30A909D9-BC7A-4257-BE09-6F781AD6471F", an 219 event with that group-URI will be applied to all three. 221 By default, an event will apply to a matching response regardless of 222 the headers used to select it (as indicated by the Vary response 223 header). However, a particular event type can be specified to 224 override this behaviour. 226 Note that an event MUST NOT be applied to responses whose channel- 227 extension does not indicate that the response is associated with the 228 channel that the event occurred in. 230 3.3. Atom Cache Channels 232 The Atom Syndication Format [2] -- when used with channel-specific 233 extensions in a specific pattern over HTTP -- is one suitable cache 234 channel transport. 236 A channel is subscribed to by commencing regular polling of the 237 channel-URI. Polling MUST be attempted at least as often as the 238 channel's precision, as indicted by the cc:precision feed extension. 240 The feed's 'current' link relation value MUST contain the channel- 241 URI, which MUST be a HTTP URI. 243 The channel is considered disconnected when the last successful poll 244 occurred more than channel-precision seconds ago, or a successful 245 poll has not yet occurred. A successful poll is defined as one that 246 results in a fresh (according to the HTTP caching model) copy of a 247 well-formed, valid feed document with a 'self' link relation whose 248 value is character-for-character identical to the channel-URI. 250 The feed SHOULD be archived [6] to allow the full state of the 251 channel to be reconstructed, while minimising the amount of bandwidth 252 that polling the channel consumes. If a feed is archived, the 253 channel is only considered connected when the entire contents of the 254 logical feed. 256 The cc:lifetime feed extension indicates the minimum span of time 257 that events are available in the logical feed for. 259 Entries in the feed represent events, in reverse-chronological order. 260 The atom:link element(s) with the "alternate" relation determines the 261 URI(s) that an event is applicable to. 263 3.3.1. The 'cc:precision' Feed Extension 265 An Atom cache channel's precision is indicated by the cc:precision 266 element. This is an feed-level extension element whose content 267 indicates the precision in seconds. 269 For example; 271 60 273 indicates that the precision of the channel it occurs in is one 274 minute. 276 3.3.2. The 'cc:lifetime' Feed Extension 278 An Atom cache channel's lifetime is indicated by the cc:lifetime 279 element. This is an feed-level extension element whose content 280 indicates the lifetime in seconds. 282 For example; 284 2592000 286 indicates that the lifetime of the channel it occurs in is 30 days. 288 3.3.3. Example 290 292 Invalidations for www.example.org 293 http://admin.example.org/events/ 294 296 298 2007-04-13T11:23:42Z 299 300 Administrator 301 web-admin@example.org 302 303 60 304 2592000 305 306 stale 307 http://admin.example.org/events/1124 308 2007-04-13T11:23:42Z 309 310 311 312 313 stale 314 http://admin.example.org/events/1125 315 2007-04-13T10:31:01Z 316 317 318 319 320 322 This feed document contains two events, the most recent applying to 323 the URI "urn:uuid:50D3565C-97A8-40E1-A5C8-CFA070166FEF" and the other 324 to "http://www.example.org/img/123.gif" and 325 "http://www.example.org/img/123.png". The previous archive document 326 is located at "http://admin.example.org/events/archive/1234", to 327 allow the client to reconstruct missed events if necessary. The 328 channel it represents has a precision of 60 seconds (thereby telling 329 clients that they need to poll at least that often), and a lifetime 330 of 30 days. 332 4. Manging Freshness with Cache Channels 334 One use of cache channels is the management of cached responses' 335 freshness lifetime. This is achieved through use of the 'channel- 336 maxage' response Cache-Control extension, which allows subscribed 337 caches to extend the freshness of a response until an applicable 338 'stale' cache channel event is received. 340 4.1. The 'channel-maxage' Response Cache-Control Extension 342 The channel-maxage response cache-control extension allows controlled 343 extension of the freshness lifetime of a cached response. 345 channel-maxage = "channel-maxage" [ "=" delta-seconds ] 347 A response containing this extension MAY be considered fresh when all 348 of the following conditions are true; 350 o The cache is connected to the channel indicated by the channel- 351 URI. 352 o The channel does not contain a 'stale' event applicable to the 353 cached response. 354 o The response's current_age (as per HTTP [1], Section 13.2.3) is no 355 more than delta-seconds, if specified. 357 For example a response with this Cache-Control header; 359 Cache-Control: channel="http://admin.example.org/events/current", 360 channel-maxage=86400, max-age=30 362 will be considered fresh for 30 seconds by a cache that is not 363 subscribed to the channel "http://admin.example.org/events/current", 364 but can be considered fresh for up to a day by one that is, as long 365 as the channel is connected and does not contain an applicable 366 'stale' event. 368 Or, if the response contains; 370 Cache-Control: channel="http://admin.example.org/events/current", 371 channel-maxage, max-age=30 373 then it will be considered fresh for up to the channels' lifetime, 374 provided that the channel is connected and does not contain a 'stale' 375 event. 377 4.2. The 'stale' Cache Channel Event 379 Cache channels can indicate that all cached responses associated with 380 a URI are to be considered stale with the 'stale' event. In Atom 381 channels, this event is indicated by the cc:stale entry-level 382 extension; 383 385 When received, this event indicates that any cached response 386 associated with the event's URI(s) MUST be considered stale (for 387 purposes of extension by channel-maxage) within channel-precision 388 seconds. 390 5. Security Considerations 392 Subscribing to a cache channel may incur more traffic than would 393 otherwise be generated by typical operation of a cache. Attackers 394 might use this to cause an implementation to subscribe to many 395 channels, reducing their capacity or even denying service. As a 396 result, caches that implement this protocol should have some 397 mechanism of limiting or controlling the channels that will be 398 subscribed to. 400 The information in a cache channel may be considered sensitive by its 401 publisher; in this case, they should require credentials to be 402 presented by subscribers. 404 6. Normative References 406 [1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 407 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 408 HTTP/1.1", RFC 2616, June 1999. 410 [2] Nottingham, M. and R. Sayre, "The Atom Syndication Format", 411 RFC 4287, December 2005. 413 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 414 Levels", BCP 14, RFC 2119, March 1997. 416 [4] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 417 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 418 January 2005. 420 [5] Bray, T., Hollander, D., and A. Layman, "Namespaces in XML", W3C 421 REC REC-xml-names-19990114, January 1999. 423 [6] Nottingham, M., "Feed Paging and Archiving", RFC 5005, 424 September 2007. 426 Appendix A. Acknowledgements 428 Henrik Nordstrom has given invaluable advice and feedback on the 429 design of this specification. Thanks also to Jeff McCarrell, John 430 Nienart, Evan Torrie, and Chris Westin for their suggestions. The 431 author takes all responsibility for errors and omissions. 433 Appendix B. Operational Considerations 435 There are a number of aspects to considered when using cache 436 channels; 438 o They are most efficient when a small number of channels (ideally, 439 one) is used to convey events about a large number of associated 440 resources (e.g., an entire Web site, or a number of related 441 sites). 442 o In particular, when using Atom channels care should be taken to 443 assure that the additional requests necessary to poll the channel 444 are offset by the load reduction achieved. In doing so, the 445 anticipated number of clients, channel-precision, change rate for 446 cached responses and number of responses being monitored by the 447 channel need to be considered. 448 o Feed documents from Atom-based channels should be cacheable, to 449 allow clusters of caches and cache hierarchies to share them more 450 efficiently. 451 o When using channels to update freshness information, it is 452 critical to assure that any new content is actually available 453 before events are propagated; if the event is too early and stale 454 cached content forces revalidation, it is possible that the 455 updated content will not be loaded into cache. 456 o Responses that use the channel-maxage mechanism should also 457 specify a max-age, both to allow channel-naive caches to store 458 them in a limited fashion, and also to allow some types of channel 459 implementations to initially store the response before 460 subscribing. 462 Appendix C. Implementation Notes 464 Handling of the 'stale' event in order to extend freshness can often 465 be effected in an existing cache implementation with only small 466 changes. 468 In particular, most caches can be easily modified to call a function 469 (whether in-process or in a separate process) when a stale response 470 is found, before the decision to validate it on the origin server is 471 made. Using the request-URI, the stored Cache-Control response 472 header and the age of the cached response as input, such a function 473 should return either STALE, which indicates that the cached response 474 is in fact stale, or FRESH, along with an indication of how much the 475 freshness lifetime should be extended by. 477 This function determines its response based upon its application of 478 the following rules to the state that is collected about the channel 479 in question; 481 o If there is no channel-maxage directive in the Cache-Control 482 response header, STALE can be returned immediately. 483 o If the channel-URI is missing from the Cache-Control response 484 header, the response is assumed to not be associated with any 485 channel, and a STALE can immediately be returned. 486 o If the channel is unsubscribed, it should be scheduled for 487 subscription, and STALE returned. 488 o If the channel is disconnected, return STALE. 489 o If there is a 'stale' event in the channel that applies to the 490 request-URI or group-URI (if present), and cached response's age 491 is greater than the age of the of that event, return STALE. 492 o If the cached response's age is greater than channel-maxage, 493 return STALE. 494 o If the cached response's age is greater than the channel's 495 lifetime, return STALE. 496 o Otherwise, return FRESH freshness=[channel-precision]. 498 Author's Address 500 Mark Nottingham 501 Yahoo! Inc. 503 Email: mnot@yahoo-inc.com 504 URI: http://www.mnot.net/ 506 Full Copyright Statement 508 Copyright (C) The IETF Trust (2007). 510 This document is subject to the rights, licenses and restrictions 511 contained in BCP 78, and except as set forth therein, the authors 512 retain all their rights. 514 This document and the information contained herein are provided on an 515 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 516 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 517 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 518 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 519 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 520 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 522 Intellectual Property 524 The IETF takes no position regarding the validity or scope of any 525 Intellectual Property Rights or other rights that might be claimed to 526 pertain to the implementation or use of the technology described in 527 this document or the extent to which any license under such rights 528 might or might not be available; nor does it represent that it has 529 made any independent effort to identify any such rights. Information 530 on the procedures with respect to rights in RFC documents can be 531 found in BCP 78 and BCP 79. 533 Copies of IPR disclosures made to the IETF Secretariat and any 534 assurances of licenses to be made available, or the result of an 535 attempt made to obtain a general license or permission for the use of 536 such proprietary rights by implementers or users of this 537 specification can be obtained from the IETF on-line IPR repository at 538 http://www.ietf.org/ipr. 540 The IETF invites any interested party to bring to its attention any 541 copyrights, patents or patent applications, or other proprietary 542 rights that may cover technology that may be required to implement 543 this standard. Please address the information to the IETF at 544 ietf-ipr@ietf.org. 546 Acknowledgment 548 Funding for the RFC Editor function is provided by the IETF 549 Administrative Support Activity (IASA).