< draft-nottingham-linked-cache-inv-00.txt		draft-nottingham-linked-cache-inv-01.txt >
	Network Working Group M. Nottingham		Network Working Group M. Nottingham
	Internet-Draft M. Kelly		Internet-Draft M. Kelly
	Intended status: Informational May 27, 2011		Intended status: Informational November 25, 2011
	Expires: November 28, 2011		Expires: May 28, 2012
	Linked Cache Invalidation		Linked Cache Invalidation
	draft-nottingham-linked-cache-inv-00		draft-nottingham-linked-cache-inv-01
	Abstract		Abstract
	This memo defines Web link types that invalidate HTTP caches, along		This memo defines Web link types that invalidate HTTP caches, along
	with an HTTP cache-control extension that allows caches that		with an HTTP cache-control extension that allows caches that
	understand those link types to use responses containing them.		understand those link types to use responses containing them.
	Together, these mechanisms offer a way to avoid use of a response		Together, these mechanisms offer a way to avoid use of a response
	that has become stale due to another request that changes server-side		that has become stale due to another request that changes server-side
	state. Collectively, this is referred to as Linked Cache		state. Collectively, this is referred to as Linked Cache
	Invalidation (LCI).		Invalidation (LCI).
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	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 November 28, 2011.		This Internet-Draft will expire on May 28, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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
	skipping to change at page 3, line 28 ¶		skipping to change at page 3, line 28 ¶
	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 Web 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 resources when the state of
	one changes. It also introduces a cache-control response extension,		one changes. It also introduces a cache-control response extension,
	so that responses using the relations can be made cached by		so that responses using the relations can be cached by
	implementations that understand the 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/2011/05/04/hi {the blog entry}
	o http://example.com/blog/2011/05/04/hi/comments {full comments for		o http://example.com/blog/2011/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"}
	skipping to change at page 5, line 23 ¶		skipping to change at page 5, line 23 ¶
	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.
	Typically, this means that the client making the changes (e.g., the		Typically, this means that the client making the changes (e.g., the
	blog update above) will see the effects immediately, while other		blog update above) will see the effects immediately, while other
	users whose requests travel through different caches will only see		users whose requests travel through different caches will only see
	the changes once the content becomes stale (if it is cached).		the changes once the content becomes stale (if it is cached).
	This makes Linked Cache Invalidation useful in a number of use cases,		This makes Linked Cache Invalidation useful in a number of cases, but
	but not all; when it's important that changes be propagated quickly,		not all; when it's important that changes be propagated quickly, the
	the freshness lifetime of cached responses can be reduced, but there		freshness lifetime of cached responses can be reduced, but there will
	will still be lag.		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 caches, reducing (but not eliminating) these effects.
	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 is an
	indication of a state change on the server to indicate one or more		signifies a state change on the server to indicate one or more
	associated URIs whose states have also changed.		associated URIs 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
	skipping to change at page 6, line 37 ¶		skipping to change at page 6, line 37 ¶
	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.
	"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 MUST invalidate all stored responses		HTTP caches using inv-maxage to calculate freshness MUST invalidate
	whose request-URIs (after normalisation) are indicated by the		all stored responses whose request-URIs (after normalisation) are
	'invalidates' link relation type contained in a successful response		indicated by the 'invalidates' link relation type contained in a
	to a state-changing request, provided that they are allowed.		successful response to a state-changing request, provided that they
			are allowed.
	HTTP caches using inv-maxage MUST invalidate all stored responses		HTTP caches using inv-maxage to calculate freshness MUST invalidate
	containing the 'inv-by' relation that indicates the current request-		all stored responses containing the 'inv-by' relation that indicates
	URI (after normalisation) upon receipt of a successful response to a		the current request-URI (after normalisation) upon receipt of 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 7, line 26 ¶		skipping to change at page 7, line 26 ¶
	In this context, "normalisation" means, in the case of a relative		In this context, "normalisation" means, in the case of a relative
	request-URI, that it is absolutised using the value of the Host		request-URI, that it is absolutised using the value of the Host
	request header and the appropriate protocol scheme.		request header and the appropriate protocol scheme.
	Finally, an invalidation based upon "invalidates" is "allowed" if the		Finally, an invalidation based upon "invalidates" is "allowed" if the
	host part of the request-URI (if absolute) or Host request header (if		host part of the request-URI (if absolute) or Host request header (if
	the request-URI is relative) matches the host part of the target URI.		the request-URI is relative) matches the host part of the target URI.
	This prevents some types of denial-of-service attacks.		This prevents some types of denial-of-service attacks.
	Implementations SHOULD effect invalidations when they become aware of		Implementations SHOULD effect invalidations when they become aware of
	changes through other means; e.g., HTCP [RFC2756] CLR messages, or		changes through other means; e.g., HTCP [RFC2756] CLR messages, upon
	upon invalidations caused by other links (i.e., chained "cascades" of		invalidations caused by other links (i.e., chained "cascades" of
	linked invalidations).		linked invalidations), or when a changed response is seen (such as
			when HTTP validation is unsuccessful).
	6. Security Considerations		6. Security Considerations
	Linked Cache Invalidation does not guarantee that invalidations will		Linked Cache Invalidation does not guarantee that invalidations will
	be effected; e.g., they can be lost due to network issues or cache		be effected; e.g., they can be lost due to network issues or cache
	downtime. Furthermore, it does not guarantee that all caches that		downtime. Furthermore, it does not guarantee that all caches that
	understand LCI will be made aware of invalidations that happen,		understand LCI will be made aware of invalidations that happen,
	because of how they originate.		because of how they originate.
	Therefore, care should be taken that LCI invalidations are not relied		Therefore, care should be taken that LCI invalidations are not relied
End of changes. 9 change blocks.
	22 lines changed or deleted		24 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/