< draft-ietf-httpbis-immutable-01.txt		draft-ietf-httpbis-immutable-02.txt >
	HTTP Working Group P. McManus		HTTP P. McManus
	Internet-Draft Mozilla		Internet-Draft Mozilla
	Intended status: Standards Track March 13, 2017		Intended status: Standards Track April 30, 2017
	Expires: September 14, 2017		Expires: November 1, 2017
	HTTP Immutable Responses		HTTP Immutable Responses
	draft-ietf-httpbis-immutable-01		draft-ietf-httpbis-immutable-02
	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.
	Note to Readers		Note to Readers
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	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 September 14, 2017.		This Internet-Draft will expire on November 1, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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 47 ¶		skipping to change at page 2, line 47 ¶
	However some content providers never create more than one variant of		However some content providers never create more than one variant of
	a sub-resource, because they use "versioned" URLs. When these		a sub-resource, because they use "versioned" URLs. When these
	resources need an update they are simply published under a new URL,		resources need an update they are simply published under a new URL,
	typically embedding an identifier unique to that version of the		typically embedding an identifier unique to that version of the
	resource in the path, and references to the sub-resource are updated		resource in the path, and references to the sub-resource are updated
	with the new path information.		with the new path information.
	For example, "https://www.example.com/101016/main.css" might be		For example, "https://www.example.com/101016/main.css" might be
	updated and republished as "https://www.example.com/102026/main.css",		updated and republished as "https://www.example.com/102026/main.css",
	with any links that references it being changed at the same time.		with any links that reference it being changed at the same time.
	This design pattern allows a very large freshness lifetime to be used		This design pattern allows a very large freshness lifetime to be used
	for the sub-resource without guessing when it will be updated in the		for the sub-resource without guessing when it will be updated in the
	future.		future.
	Unfortunately, the user agent does not know when this versioned URL		Unfortunately, the user agent does not know when this versioned URL
	design pattern is used. As a result, user-driven refreshes still		design pattern is used. As a result, user-driven refreshes still
	translate into wasted conditional requests for each sub-resource as		translate into wasted conditional requests for each sub-resource as
	each will return 304 responses.		each will return 304 responses.
	The "immutable" HTTP response Cache-Control extension allows servers		The "immutable" HTTP response Cache-Control extension allows servers
	skipping to change at page 3, line 41 ¶		skipping to change at page 3, line 41 ¶
	normally would be in the absence of immutable.		normally would be in the absence of immutable.
	The immutable extension takes no arguments. If any arguments are		The immutable extension takes no arguments. If any arguments are
	present, they have no meaning, and MUST be ignored. Multiple		present, they have no meaning, and MUST be ignored. Multiple
	instances of the immutable extension are equivalent to one instance.		instances of the immutable extension are equivalent to one instance.
	The presence of an immutable Cache-Control extension in a request has		The presence of an immutable Cache-Control extension in a request has
	no effect.		no effect.
	2.1. About Intermediaries		2.1. About Intermediaries
	An immutable response has the same semantic meaning whe received by		An immutable response has the same semantic meaning when received by
	proxy clients as it does when received by User-Agent based clients.		proxy clients as it does when received by User-Agent based clients.
	Therefore proxies SHOULD skip conditionally revalidating fresh		Therefore proxies SHOULD skip conditionally revalidating fresh
	responses containing the immutable extension unless there is a signal		responses containing the immutable extension unless there is a signal
	from the client that a validation is necessary (e.g. a no-cache		from the client that a validation is necessary (e.g. a no-cache
	Cache-Control request directive).		Cache-Control request directive).
	A proxy that uses immutable to bypass a conditional revalidation may		A proxy that uses immutable to bypass a conditional revalidation may
	choose whether to reply with a 304 or 200 to its requesting client		choose whether to reply with a 304 or 200 to its requesting client
	based on the request headers the proxy received.		based on the request headers the proxy received.
End of changes. 6 change blocks.
	7 lines changed or deleted		7 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/