< draft-mcmanus-immutable-00.txt		draft-mcmanus-immutable-01.txt >
	Network Working Group P. McManus		Network Working Group P. McManus
	Internet-Draft Mozilla		Internet-Draft Mozilla
	Intended status: Standards Track October 26, 2016		Intended status: Standards Track December 19, 2016
	Expires: April 29, 2017		Expires: June 22, 2017
	HTTP Immutable Responses		HTTP Immutable Responses
	draft-mcmanus-immutable-00		draft-mcmanus-immutable-01
	Abstract		Abstract
	The immutable HTTP response Cache-Control extension allows servers to		The immutable HTTP response Cache-Control extension allows servers to
	identify resources that will not be updated during their freshness		identify resources that will not be updated during their freshness
	lifetime. This assures that a client never needs to revalidate a		lifetime. This assures that a client never needs to revalidate a
	cached fresh resource to be certain it has not been modified.		cached fresh resource to be certain it has not been modified.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	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 April 29, 2017.		This Internet-Draft will expire on June 22, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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 2, line 35 ¶		skipping to change at page 2, line 35 ¶
	requests to refresh all portions of a common HTML page [REQPERPAGE].		requests to refresh all portions of a common HTML page [REQPERPAGE].
	Through the use of the versioned URL design pattern some content		Through the use of the versioned URL design pattern some content
	providers never create more than one variant of a sub-resource. When		providers never create more than one variant of a sub-resource. When
	these resources need an update they are simply published under a new		these resources need an update they are simply published under a new
	URL, typically embedding a variant identifier in the path, and		URL, typically embedding a variant identifier in the path, and
	references to the sub-resource are updated with the new path		references to the sub-resource are updated with the new path
	information.		information.
	For example, https://www.example.com/101016/main.css might be updated		For example, https://www.example.com/101016/main.css might be updated
	and republished as https://102026/main.css and the html that		and republished as https://www.example.com/102026/main.css and the
	references it is changed at the same time. This design pattern		html that references it is changed at the same time. This design
	allows a very large freshness lifetime to be applied to the sub-		pattern allows a very large freshness lifetime to be applied to the
	resource without guessing when it will be updated in the future.		sub-resource without guessing when it will be updated in the future.
	Unfortunately, the user-agent is not aware of the versioned URL		Unfortunately, the user-agent is not aware of the versioned URL
	design pattern. User driven refresh events still translate into		design pattern. User driven refresh events still translate into
	wasted conditional requests for each sub-resource as each will return		wasted conditional requests for each sub-resource as each will return
	304 responses.		304 responses.
	The immutable HTTP response Cache-Control extension allows servers to		The immutable HTTP response Cache-Control extension allows servers to
	identify resources that will not be updated during their freshness		identify resources that will not be updated during their freshness
	lifetime. This effectively instructs the client that any conditional		lifetime. This effectively instructs the client that any conditional
	request for a previously served variant of that resource may be		request for a previously served variant of that resource may be
	skipping to change at page 3, line 21 ¶		skipping to change at page 3, line 21 ¶
	The immutable extension only applies during the freshness lifetime of		The immutable extension only applies during the freshness lifetime of
	the response. Stale responses SHOULD be revalidated as they normally		the response. Stale responses SHOULD be revalidated as they normally
	would be in the absence of immutable.		would be in the absence of immutable.
	The immutable extension takes no arguments and if any arguments are		The immutable extension takes no arguments and if any arguments are
	present they have no meaning. Multiple instances of the immutable		present they have no meaning. Multiple instances of the immutable
	extension are equivalent to one instance. The presence of an		extension are equivalent to one instance. The presence of an
	immutable Cache-Control extension in a request has no effect.		immutable Cache-Control extension in a request has no effect.
	2.1. Example		2.1. About Intermediaries
			An immutable response has the same semantic meaning for proxy clients
			as it does for User-Agent based clients and they therefore MAY also
			presume a conditional revalidation for a response marked immutable
			would return 304. A proxy client who uses immutable to anticipate a
			304 response may choose whether to reply with a 304 or 200 to its
			requesting client.
			2.2. Example
	Cache-Control: max-age=31536000, immutable		Cache-Control: max-age=31536000, immutable
	3. Security Considerations		3. Security Considerations
	The immutable mechanism acts as form of soft pinning and, as with all		The immutable mechanism acts as form of soft pinning and, as with all
	pinning mechanisms, creates a vector for the amplification of a cache		pinning mechanisms, creates a vector for amplification of cache
	poisoning attack. Two mechanisms are suggested for mitigation of		corruption incidents. These incidents include cache poisoning
	this risk:		attacks. Three mechanisms are suggested for mitigation of this risk:
	o Clients should ignore immutable for resources that are not part of		o Clients should ignore immutable for resources that are not part of
	a secure context [SECURECONTEXTS]. Authenticated resources are		an authenticated context such as HTTPS. Authenticated resources
	less vulnerable to cache poisoning.		are less vulnerable to cache poisoning.
	o User-Agents often provide two different refresh mechanisms: reload		o User-Agents often provide two different refresh mechanismss:
	and some form of force-reload. The latter is used to rectify		reload and some form of force-reload. The latter is used to
	interrupted loads and other corruption. These reloads should		rectify interrupted loads and other corruption. These reloads,
			typically indicated through no-cache request attributes, should
	ignore immutable as well.		ignore immutable as well.
			o Clients should ignore immutable for resources that do not provide
			a strong indication that the stored response size is the correct
			response size such as responses delimited by connection close.
	4. IANA Considerations		4. IANA Considerations
	[RFC7234] sections 7.1 and 7.1.2 require registration of the		[RFC7234] sections 7.1 and 7.1.2 require registration of the
	immutable extension in the "Hypertext Transfer Protocol (HTTP) Cache		immutable extension in the "Hypertext Transfer Protocol (HTTP) Cache
	Directive Registry" with IETF Review.		Directive Registry" with IETF Review.
	o Cache-Directive: immutable		o Cache-Directive: immutable
	o Pointer to specification text: [this document]		o Pointer to specification text: [this document]
	5. Acknowledgments		5. Acknowledgments
	Thank you to Ben Maurer for partnership in developing and testing		Thank you to Ben Maurer for partnership in developing and testing
	this idea.		this idea. Thank you to Amos Jeffries for help with proxy
			interactions.
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Semantics and Content", RFC 7231,		Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
	DOI 10.17487/RFC7231, June 2014,		DOI 10.17487/RFC7231, June 2014,
	<http://www.rfc-editor.org/info/rfc7231>.		<http://www.rfc-editor.org/info/rfc7231>.
	skipping to change at page 4, line 31 ¶		skipping to change at page 4, line 46 ¶
	DOI 10.17487/RFC7232, June 2014,		DOI 10.17487/RFC7232, June 2014,
	<http://www.rfc-editor.org/info/rfc7232>.		<http://www.rfc-editor.org/info/rfc7232>.
	[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",		Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
	RFC 7234, DOI 10.17487/RFC7234, June 2014,		RFC 7234, DOI 10.17487/RFC7234, June 2014,
	<http://www.rfc-editor.org/info/rfc7234>.		<http://www.rfc-editor.org/info/rfc7234>.
	6.2. Informative References		6.2. Informative References
	[SECURECONTEXTS]
	West, M., "Secure Contexts", n.d., <https://w3c.github.io/
	webappsec-secure-contexts/>.
	[REQPERPAGE]		[REQPERPAGE]
	"HTTP Archive", n.d.,		"HTTP Archive", n.d.,
	<http://httparchive.org/interesting.php#reqTotal>.		<http://httparchive.org/interesting.php#reqTotal>.
	Author's Address		Author's Address
	Patrick McManus		Patrick McManus
	Mozilla		Mozilla
	Email: pmcmanus@mozilla.com		Email: pmcmanus@mozilla.com
End of changes. 11 change blocks.
	22 lines changed or deleted		33 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/