< draft-nottingham-linked-cache-inv-01.txt		draft-nottingham-linked-cache-inv-02.txt >
	Network Working Group M. Nottingham		Network Working Group M. Nottingham
	Internet-Draft M. Kelly		Internet-Draft M. Kelly
	Intended status: Informational November 25, 2011		Intended status: Informational June 1, 2012
	Expires: May 28, 2012		Expires: December 3, 2012
	Linked Cache Invalidation		Linked Cache Invalidation
	draft-nottingham-linked-cache-inv-01		draft-nottingham-linked-cache-inv-02
	Abstract		Abstract
	This memo defines Web link types that invalidate HTTP caches, along		This memo defines two new link types that indicate relationships
	with an HTTP cache-control extension that allows caches that		between resources in terms of cache invalidation, along with a HTTP
	understand those link types to use responses containing them.		cache-control extension that takes advantage of those relationships
	Together, these mechanisms offer a way to avoid use of a response		to use them to extend response freshness. Collectively, this is
	that has become stale due to another request that changes server-side		referred to as Linked Cache Invalidation (LCI).
	state. Collectively, this is referred to as Linked Cache
	Invalidation (LCI).
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on May 28, 2012.		This Internet-Draft will expire on December 3, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2012 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document.		to this document.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 5		2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 5
	3. The 'invalidates' link relation type . . . . . . . . . . . . . 5		3. The 'invalidates' link relation type . . . . . . . . . . . . . 5
	4. The 'inv-by' link relation type . . . . . . . . . . . . . . . . 6		4. The 'inv-by' link relation type . . . . . . . . . . . . . . . . 5
	5. The 'inv-maxage' response cache-control extension . . . . . . . 6		5. The 'inv-maxage' response cache-control extension . . . . . . . 6
	6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7		6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 8		8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
	8.2. Informative References . . . . . . . . . . . . . . . . . . 8		8.2. Informative References . . . . . . . . . . . . . . . . . . 8
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 8		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	In normal operation, a HTTP [RFC2616] cache will invalidate a stored		In normal operation, a HTTP [RFC2616] cache will invalidate a stored
	response if a state-changing request (e.g., POST, PUT or DELETE) is		response if an unsafe request (e.g., POST, PUT or DELETE) is made to
	made for that URI. HTTP also provides for such a state-changing		its URI. HTTP also provides for such a state-changing request to
	request to invalidate related resources (using the Location and		invalidate related resources (using the Location and Content-Location
	Content-Location headers in the response), but this is of limited		headers in the response), but this is of limited utility, because
	utility, because those headers have defined semantics, and can only		those headers have defined semantics, and can only occur once each.
	occur once each.
	Because of this, it is not practical to make a response that depends		Because of this, it is not practical to make a response that depends
	on the state of another resource cacheable. For example, an update		on the state of another resource cacheable. For example, an update
	to a blog entry might change several different resources, such as the		to a blog entry might change several different resources, such as the
	user's summary page, the blog's "front" page, the blog's Atom feed,		user's summary page, the blog's "front" page, the blog's Atom feed,
	and of course the blog entry itself. If any of these resources is		and of course the blog entry itself. If any of these resources is
	made cacheable, it will not reflect those changes, causing confusion		made cacheable, it will not reflect those changes, causing confusion
	if the user tries to verify that their changes have been correctly		if the user tries to verify that their changes have been correctly
	applied.		applied.
	This memo introduces new Web link relation types [RFC5988] that allow		This memo introduces new link relation types [RFC5988] that allow
	more fine-grained relationships between resources to be defined, so		more fine-grained relationships between resources to be defined, so
	that caches can invalidate all related resources when the state of		that caches can invalidate all related representations when the state
	one changes. It also introduces a cache-control response extension,		of one changes. It also introduces a cache-control response
	so that responses using the relations can be cached by		extension, so that responses using the relations can be cached by
	implementations that understand these relations.		implementations that understand these relations.
	1.1. Example		1.1. Example
	Taking the blog use case described above, imagine that we have the		Taking the blog use case described above, imagine that we have the
	following related resources:		following related resources:
	o http://example.com/blog/2011/05/04/hi {the blog entry}		o http://example.com/blog/2012/05/04/hi [the blog entry]
	o http://example.com/blog/2011/05/04/hi/comments {full comments for		o http://example.com/blog/2012/05/04/hi/comments [full comments for
	the entry}		the entry]
	o http://example.com/blog/ {the blog "home"}		o http://example.com/blog/ {the blog "home"}
	o http://example.com/users/bob/ {the user page, listing his entries}		o http://example.com/users/bob/ [the user page, listing his entries]
	When someone comments on Bob's blog entry, they might send a request		When someone comments on Bob's blog entry, they might send a request
	like this:		like this:
	POST /cgi-bin/blog.cgi HTTP/1.1		POST /cgi-bin/blog.cgi HTTP/1.1
	Host: example.com		Host: example.com
	Content-Type: application/x-www-form-urlencoded		Content-Type: application/x-www-form-urlencoded
	Content-Length: 7890		Content-Length: 7890
	[...]		[...]
	This request (if successful) should have the effect of invalidating		When the comment is successful, it's typical to redirect the client
	the related resources listed above.
	If the comment is successful, it's typical to redirect the client
	back to the original blog page, with a response like this:		back to the original blog page, with a response like this:
	HTTP/1.1 302 Moved Temporarily		HTTP/1.1 302 Moved Temporarily
	Location: http://example.com/blog/2011/05/04/hi		Location: http://example.com/blog/2012/05/04/hi
	Content-Length: 0		Content-Length: 0
	Which would invalidate the blog entry URI, as per HTTP's normal		Which would invalidate the blog entry URI, as per HTTP's normal
	operation.		operation.
	To invalidate the full comments page for the entry, the relationship		To invalidate the full comments page for the entry, the relationship
	can be described in that page's response headers:		can be described in that page's response headers:
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Content-Type: text/html		Content-Type: text/html
	Content-Length: 5555		Content-Length: 5555
	Link: </blog/2011/05/04/hi>; rel="inv-by"		Link: </blog/2012/05/04/hi>; rel="inv-by"
	Cache-Control: no-cache, inv-maxage=600		Cache-Control: no-cache, inv-maxage=600
	[...]		[...]
	This declares that whenever the entry page (the target of the link		This declares that whenever the entry page (the target of the link
	header) changes, this response (the full comments page) changes as		header) changes, this response (the full comments page) changes as
	well; it's invalidated by the link target.		well; it's invalidated by the link target.
	Note that the full comments page also carries a Cache-Control header		Note that the full comments page also carries a Cache-Control header
	that instructs "normal" caches not to reuse this response, but allows		that instructs "normal" caches not to reuse this response, but allows
	those caches that are aware of LCI to consider it fresh for ten		those caches that are aware of LCI to consider it fresh for ten
	minutes.		minutes.
	To invalidate the blog home page and user page, it's impractical to		To invalidate the blog home page and user page, it's impractical to
	list all of the resources that might change if a new entry is posted;		list all of the resources that might change if a new entry is posted;
	not only are there many of them, but their URLs might not be known		not only are there many of them, but their URLs might not be known
	when the pages are cached. To address this, the POST response itself		when the pages are cached. To address this, the POST response itself
	can nominate resources to invalidate, using the 'invalidates'		(i.e., when the comment is made) can nominate resources to
	relation, making that response:		invalidate, using the 'invalidates' relation, making that response:
	HTTP/1.1 302 Moved Temporarily		HTTP/1.1 302 Moved Temporarily
	Location: http://example.com/blog/2011/05/04/hi		Location: http://example.com/blog/2012/05/04/hi
	Link: <http://example.com/blog/>; rel="invalidates",		Link: <http://example.com/blog/>; rel="invalidates",
	<http://example.com/users/bob/>; rel="invalidates"		<http://example.com/users/bob/>; rel="invalidates"
	Content-Length: 0		Content-Length: 0
	Depending on how important it is to see updates on the home page and		Depending on how important it is to see updates on the home page and
	user page, those responses can either allow caching regardless of		user page, those responses can either allow caching regardless of
	support for LCI, like this:		support for LCI, like this:
	Cache-Control: max-age=300		Cache-Control: max-age=300
	... or they can only allow caching by LCI-aware caches, like this:		... or they can only allow caching by LCI-aware caches, like this:
	Cache-Control: no-cache, inv-maxage=300		Cache-Control: no-cache, inv-maxage=300
	Together, these techniques can be used to invalidate a variety of		Together, these techniques can be used to invalidate a variety of
	related responses.		related responses.
	It is important to note that the invalidations are only effective in		It is important to note that the invalidations are only effective in
	the caches that the client's request stream travels through.		the caches that the client's request stream travels through. This
	Typically, this means that the client making the changes (e.g., the		means other caches will continue to serve the "old" content until the
	blog update above) will see the effects immediately, while other		invalidation event is propagated to them (see below) or the cached
	users whose requests travel through different caches will only see		responses become stale.
	the changes once the content becomes stale (if it is cached).
	This makes Linked Cache Invalidation useful in a number of cases, but
	not all; when it's important that changes be propagated quickly, the
	freshness lifetime of cached responses can be reduced, but there will
	still be lag.
	When multiple caches are close together, the HyperText Caching		When multiple caches are close together, the HyperText Caching
	Protocol (HTCP) [RFC2756] can be used to propagate invalidation		Protocol (HTCP) [RFC2756] can be used to propagate invalidation
	events between caches, reducing (but not eliminating) these effects.		events between them.
	2. Notational Conventions		2. Notational Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	This document uses the Augmented Backus-Naur Form (ABNF) notation of		This document uses the Augmented Backus-Naur Form (ABNF) notation of
	[RFC2616], and explicitly includes the following rules from it:		[RFC2616], and explicitly includes the following rules from it:
	delta-seconds.		delta-seconds.
	3. The 'invalidates' link relation type		3. The 'invalidates' link relation type
	The 'invalidates' link relation type allows a response that is an		The 'invalidates' link relation type allows a response that signifies
	signifies a state change on the server to indicate one or more		a state change on the server to indicate one or more associated URIs
	associated URIs whose states have also changed.		whose states have also changed.
	o Relation name: invalidates		o Relation name: invalidates
	o Description: Indicates that when the link context changes, the		o Description: Indicates that when the link context changes, the
	link target also has changed.		link target also has changed.
	o Reference: [this document]		o Reference: [this document]
	o Notes:		o Notes:
	4. The 'inv-by' link relation type		4. The 'inv-by' link relation type
	The 'inv-by' link relation type allows a response to nominate one or		The 'inv-by' link relation type allows a response to nominate one or
	skipping to change at page 6, line 28 ¶		skipping to change at page 6, line 15 ¶
	o Relation name: inv-by		o Relation name: inv-by
	o Description: Indicates that when the link target changes, the		o Description: Indicates that when the link target changes, the
	link's context has also changed.		link's context has also changed.
	o Reference: [this document]		o Reference: [this document]
	o Notes:		o Notes:
	5. The 'inv-maxage' response cache-control extension		5. The 'inv-maxage' response cache-control extension
	When present, the 'inv-maxage' cache-control extension indicates the		When present, the 'inv-maxage' cache-control extension indicates the
	number of seconds that caches who implement Linked Cache invalidation		number of seconds that caches who implement Linked Cache invalidation
	can consider responses fresh for.		can consider responses fresh for, provided they are not invalidated.
	"inv-maxage" "=" delta-seconds		"inv-maxage" "=" delta-seconds
	HTTP caches MAY, if they fully implement this specification,		HTTP caches MAY, if they fully implement this specification,
	disregard the HTTP response cache-control directives 'no-cache',		disregard the HTTP response cache-control directives 'no-cache',
	'max-age' and 's-maxage' and use the value of inv-maxage as a		'max-age' and 's-maxage' and use the value of inv-maxage as a
	replacement for max-age.		replacement for max-age.
	HTTP caches using inv-maxage to calculate freshness MUST invalidate		HTTP caches using inv-maxage to calculate freshness MUST invalidate
	all stored responses whose request-URIs (after normalisation) are		all stored responses whose request-URIs (after normalisation) are the
	indicated by the 'invalidates' link relation type contained in a		target of a 'invalidates' link relation contained in a successful
	successful response to a state-changing request, provided that they		response to a state-changing request, provided that they are allowed.
	are allowed.
	HTTP caches using inv-maxage to calculate freshness MUST invalidate		HTTP caches using inv-maxage to calculate freshness MUST invalidate
	all stored responses containing the 'inv-by' relation that indicates		all stored responses containing a 'inv-by' link relation whose target
	the current request-URI (after normalisation) upon receipt of a		is the current request-URI (after normalisation) upon receipt of a
			successful response to a state-changing request.
			Likewise, HTTP caches using inv-maxage to calculate freshness MUST
			invalidate all stored responses containing a 'inv-by' link relation
			whose target is the content of either the Location or Content-
			Location response headers (after normalisation) upon receipt of a
	successful response to a state-changing request.		successful response to a state-changing request.
	Here, a response is considered to "contain" a link relation if it is		Here, a response is considered to "contain" a link relation if it is
	carried in the Link HTTP header [RFC5988]. I.e., it is not necessary		carried in the Link HTTP header [RFC5988]. I.e., it is not necessary
	to look at the response body.		to look at the response body.
	"Invalidate" means that the cache will either remove all stored		"Invalidate" means that the cache will either remove all stored
	responses related to the effective request URI, or will mark these as		responses related to the effective request URI, or will mark these as
	"invalid" and in need of a mandatory validation before they can be		"invalid" and in need of a mandatory validation before they can be
	returned in response to a subsequent request.		returned in response to a subsequent request.
	skipping to change at page 8, line 7 ¶		skipping to change at page 8, line 4 ¶
	under certain circumstances (e.g., arranging for one request to		under certain circumstances (e.g., arranging for one request to
	invalidate a large number of responses), leading to a reduction in		invalidate a large number of responses), leading to a reduction in
	service quality.		service quality.
	7. IANA Considerations		7. IANA Considerations
	This document registers two entries in the Link Relation Type		This document registers two entries in the Link Relation Type
	Registry; see Section 3 and Section 4.		Registry; see Section 3 and Section 4.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext		Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.		Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
	[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.		[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
	8.2. Informative References		8.2. Informative References
	[RFC2756] Vixie, P. and D. Wessels, "Hyper Text Caching Protocol		[RFC2756] Vixie, P. and D. Wessels, "Hyper Text Caching Protocol
	(HTCP/0.0)", RFC 2756, January 2000.		(HTCP/0.0)", RFC 2756, January 2000.
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	Thanks to Michael Hausenblas for his input.		Thanks to Michael Hausenblas for his input.
	The authors take all responsibility for errors and omissions.
	Authors' Addresses		Authors' Addresses
	Mark Nottingham		Mark Nottingham
	Email: mnot@mnot.net		Email: mnot@mnot.net
	URI: http://www.mnot.net/		URI: http://www.mnot.net/
	Mike Kelly		Mike Kelly
	Email: mike@stateless.co		Email: mike@stateless.co
End of changes. 25 change blocks.
	61 lines changed or deleted		50 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/