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).