draft-reschke-http-status-308-05.txt		draft-reschke-http-status-308-latest.txt
	Network Working Group J. Reschke		Network Working Group J. Reschke
	Internet-Draft greenbytes		Internet-Draft greenbytes
	Intended status: Experimental February 14, 2012		Intended status: Experimental March 2013
	Expires: August 17, 2012		Expires: September 2, 2013
	The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent		The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent
	Redirect)		Redirect)
	draft-reschke-http-status-308-05		draft-reschke-http-status-308-latest
	Abstract		Abstract
	This document specifies the additional HyperText Transfer Protocol		This document specifies the additional HyperText Transfer Protocol
	(HTTP) Status Code 308 (Permanent Redirect).		(HTTP) Status Code 308 (Permanent Redirect).
	Editorial Note (To be removed by RFC Editor before publication)		Editorial Note (To be removed by RFC Editor before publication)
	Distribution of this document is unlimited. Although this is not a		Distribution of this document is unlimited. Although this is not a
	work item of the HTTPbis Working Group, comments should be sent to		work item of the HTTPbis Working Group, comments should be sent to
	skipping to change at page 2, line 4		skipping to change at page 2, line 4
	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 August 17, 2012.		This Internet-Draft will expire on September 2, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2013 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. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 30		skipping to change at page 2, line 30
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3		2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
	3. 308 Permanent Redirect . . . . . . . . . . . . . . . . . . . . 3		3. 308 Permanent Redirect . . . . . . . . . . . . . . . . . . . . 3
	4. Deployment Considerations . . . . . . . . . . . . . . . . . . . 4		4. Deployment Considerations . . . . . . . . . . . . . . . . . . . 4
	5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5		5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
	8. Normative References . . . . . . . . . . . . . . . . . . . . . 5		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
			8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
			8.2. Informative References . . . . . . . . . . . . . . . . . . 6
	Appendix A. Implementations (to be removed by RFC Editor		Appendix A. Implementations (to be removed by RFC Editor
	before publication) . . . . . . . . . . . . . . . . . 6		before publication) . . . . . . . . . . . . . . . . . 7
	Appendix B. Change Log (to be removed by RFC Editor before		Appendix B. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . . 6		publication) . . . . . . . . . . . . . . . . . . . . . 7
	B.1. Since draft-reschke-http-status-308-00 . . . . . . . . . . 6		B.1. Since draft-reschke-http-status-308-00 . . . . . . . . . . 7
	B.2. Since draft-reschke-http-status-308-01 . . . . . . . . . . 6		B.2. Since draft-reschke-http-status-308-01 . . . . . . . . . . 7
	B.3. Since draft-reschke-http-status-308-02 . . . . . . . . . . 7		B.3. Since draft-reschke-http-status-308-02 . . . . . . . . . . 7
	B.4. Since draft-reschke-http-status-308-03 . . . . . . . . . . 7		B.4. Since draft-reschke-http-status-308-03 . . . . . . . . . . 7
	B.5. Since draft-reschke-http-status-308-04 . . . . . . . . . . 7		B.5. Since draft-reschke-http-status-308-04 . . . . . . . . . . 7
	Appendix C. Resolved issues (to be removed by RFC Editor		B.6. Since draft-reschke-http-status-308-05 . . . . . . . . . . 8
	before publication) . . . . . . . . . . . . . . . . . 7		B.7. Since draft-reschke-http-status-308-06 . . . . . . . . . . 8
	C.1. missingconsiderations . . . . . . . . . . . . . . . . . . . 7		B.8. Since draft-reschke-http-status-308-07 . . . . . . . . . . 8
	Appendix D. Open issues (to be removed by RFC Editor prior to		Appendix C. Open issues (to be removed by RFC Editor prior to
	publication) . . . . . . . . . . . . . . . . . . . . . 7		publication) . . . . . . . . . . . . . . . . . . . . . 8
	D.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 7		C.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	HTTP defines a set of status codes for the purpose of redirecting a		HTTP defines a set of status codes for the purpose of redirecting a
	request to a different URI ([RFC3986]). The history of these status		request to a different URI ([RFC3986]). The history of these status
	codes is summarized in Section 7.3 of		codes is summarized in Section 6.4 of
	[draft-ietf-httpbis-p2-semantics], which also classifies the existing		[draft-ietf-httpbis-p2-semantics], which also classifies the existing
	status codes into four categories.		status codes into four categories.
	The first of these categories contains the status codes 301 (Moved		The first of these categories contains the status codes 301 (Moved
	Permanently), 302 (Found), and 307 (Temporary Redirect), which can be		Permanently), 302 (Found), and 307 (Temporary Redirect), which can be
	classified as below:		classified as below:
	+-------------------------------------------+-----------+-----------+		+-------------------------------------------+-----------+-----------+
	| | Permanent | Temporary |		| | Permanent | Temporary |
	+-------------------------------------------+-----------+-----------+		+-------------------------------------------+-----------+-----------+
	| Allows changing the request method from | 301 | 302 |		| Allows changing the request method from | 301 | 302 |
	| POST to GET | | |		| POST to GET | | |
	| Does not allow changing the request | - | 307 |		| Does not allow changing the request | - | 307 |
	| method from POST to GET | | |		| method from POST to GET | | |
	+-------------------------------------------+-----------+-----------+		+-------------------------------------------+-----------+-----------+
	Section 7.3.8 of [draft-ietf-httpbis-p2-semantics] states that HTTP		Section 6.4.7 of [draft-ietf-httpbis-p2-semantics] states that HTTP
	does not define a permanent variant of status code 307; this		does not define a permanent variant of status code 307; this
	specification adds the status code 308, defining this missing variant		specification adds the status code 308, defining this missing variant
	(Section 3).		(Section 3).
	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 [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. 308 Permanent Redirect		3. 308 Permanent Redirect
	The target resource has been assigned a new permanent URI and any		The target resource has been assigned a new permanent URI and any
	future references to this resource SHOULD use one of the returned		future references to this resource SHOULD use one of the returned
	URIs. Clients with link editing capabilities ought to automatically		URIs. Clients with link editing capabilities ought to automatically
	re-link references to the effective request URI (Section 4.3 of		re-link references to the effective request URI (Section 5.5 of
	[draft-ietf-httpbis-p1-messaging]) to one or more of the new		[draft-ietf-httpbis-p1-messaging]) to one or more of the new
	references returned by the server, where possible.		references returned by the server, where possible.
	Caches MAY use a heuristic (see [draft-ietf-httpbis-p6-cache],		Caches MAY use a heuristic (see [draft-ietf-httpbis-p6-cache],
	Section 2.3.1.1) to determine freshness for 308 responses.		Section 4.1.2) to determine freshness for 308 responses.
	The new permanent URI SHOULD be given by the Location field in the		The new permanent URI SHOULD be given by the Location field in the
	response ([draft-ietf-httpbis-p2-semantics], Section 9.5). A		response ([draft-ietf-httpbis-p2-semantics], Section 7.1.2). A
	response payload can contain a short hypertext note with a hyperlink		response payload can contain a short hypertext note with a hyperlink
	to the new URI(s).		to the new URI(s).
			Note: This status code is similar to 301 Moved Permanently
			(Section 6.4.2 of [draft-ietf-httpbis-p2-semantics]), except that
			it does not allow rewriting the request method from POST to GET.
	4. Deployment Considerations		4. Deployment Considerations
	Section 4 of [draft-ietf-httpbis-p2-semantics] requires recipients to		Section 6 of [draft-ietf-httpbis-p2-semantics] requires recipients to
	treat unknown 3xx status codes the same way as status code 300		treat unknown 3xx status codes the same way as status code 300
	Multiple Choices ([draft-ietf-httpbis-p2-semantics], Section 7.3.1).		Multiple Choices ([draft-ietf-httpbis-p2-semantics], Section 6.4.1).
	Thus, servers will not be able to rely on automatic redirection		Thus, servers will not be able to rely on automatic redirection
	happening similar to status codes 301, 302, or 307.		happening similar to status codes 301, 302, or 307.
	Therefore, initial use of status code 308 will be restricted to cases		Therefore, initial use of status code 308 will be restricted to cases
	where the server has sufficient confidence in the clients		where the server has sufficient confidence in the clients
	understanding the new code, or when a fallback to the semantics of		understanding the new code, or when a fallback to the semantics of
	status code 300 is not problematic.		status code 300 is not problematic. Server implementers are advised
			not to vary the status code based on characteristics of the request,
			such as the User-Agent header field ("User-Agent Sniffing") -- doing
			so usually results in both hard to maintain and hard to debug code
			and would also require special attention to caching (i.e., setting a
			"Vary" response header field, as defined in Section 7.1.4 of
			[draft-ietf-httpbis-p2-semantics]).
	Note that many existing HTML-based user agents will emulate a refresh		Note that many existing HTML-based user agents will emulate a refresh
	when encountering an HTML <meta> refresh directive. This can be used		when encountering an HTML <meta> refresh directive ([HTML]). This
	as another fallback. For example:		can be used as another fallback. For example:
	Client request:		Client request:
	GET / HTTP/1.1		GET / HTTP/1.1
	Host: example.com		Host: example.com
	Server response:		Server response:
	HTTP/1.1 308 Permanent Redirect		HTTP/1.1 308 Permanent Redirect
	Content-Type: text/html; charset=UTF-8		Content-Type: text/html; charset=UTF-8
	skipping to change at page 5, line 8		skipping to change at page 5, line 32
	The document has been moved to		The document has been moved to
	<a href="http://example.com/new"		<a href="http://example.com/new"
	>http://example.com/new</a>.		>http://example.com/new</a>.
	</p>		</p>
	</body>		</body>
	</html>		</html>
	5. Security Considerations		5. Security Considerations
	All security considerations that apply to HTTP redirects apply to the		All security considerations that apply to HTTP redirects apply to the
	308 status code as well (see Section 11 of		308 status code as well (see Section 9 of
	[draft-ietf-httpbis-p2-semantics]).		[draft-ietf-httpbis-p2-semantics]).
	6. IANA Considerations		6. IANA Considerations
	The registration below shall be added to the HTTP Status Code		The registration below shall be added to the HTTP Status Code
	Registry (defined in Section 4.2 of [draft-ietf-httpbis-p2-semantics]		Registry (defined in Section 8.2 of [draft-ietf-httpbis-p2-semantics]
	and located at <http://www.iana.org/assignments/http-status-codes>):		and located at <http://www.iana.org/assignments/http-status-codes>):
	+-------+--------------------+---------------------------------+		+-------+--------------------+---------------------------------+
	| Value | Description | Reference |		| Value | Description | Reference |
	+-------+--------------------+---------------------------------+		+-------+--------------------+---------------------------------+
	| 308 | Permanent Redirect | Section 3 of this specification |		| 308 | Permanent Redirect | Section 3 of this specification |
	+-------+--------------------+---------------------------------+		+-------+--------------------+---------------------------------+
	7. Acknowledgements		7. Acknowledgements
	The definition for the new status code 308 re-uses text from the		The definition for the new status code 308 re-uses text from the
	HTTP/1.1 definitions of status codes 301 and 307.		HTTP/1.1 definitions of status codes 301 and 307.
	Furthermore, thanks to Cyrus Daboo, Bjoern Hoehrmann, Subramanian		Furthermore, thanks to Ben Campbell, Cyrus Daboo, Eran Hammer-Lahav,
	Moonesamy, and Peter Saint-Andre for feedback on this document.		Bjoern Hoehrmann, Subramanian Moonesamy, Peter Saint-Andre, and
			Robert Sparks for feedback on this document.
	8. Normative References		8. References
			8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in		[RFC2119] Bradner, S., "Key words for use in
	RFCs to Indicate Requirement		RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119,		Levels", BCP 14, RFC 2119,
	March 1997.		March 1997.
	[RFC3986] Berners-Lee, T., Fielding, R., and		[RFC3986] Berners-Lee, T., Fielding, R., and
	L. Masinter, "Uniform Resource		L. Masinter, "Uniform Resource
	Identifier (URI): Generic Syntax",		Identifier (URI): Generic Syntax",
	STD 66, RFC 3986, January 2005.		STD 66, RFC 3986, January 2005.
	[draft-ietf-httpbis-p1-messaging] Fielding, R., Ed., Gettys, J.,		[draft-ietf-httpbis-p1-messaging] Fielding, R., Ed. and J. Reschke,
	Mogul, J., Frystyk, H., Masinter,		Ed., "Hypertext Transfer Protocol
	L., Leach, P., Berners-Lee, T.,		(HTTP/1.1): Message Syntax and
	Lafon, Y., Ed., and J. Reschke,		Routing",
	Ed., "HTTP/1.1, part 1: URIs,		draft-ietf-httpbis-p1-messaging-22
	Connections, and Message Parsing",		(work in progress), February 2013.
	draft-ietf-httpbis-p1-messaging-18
	(work in progress), January 2012.
	[draft-ietf-httpbis-p2-semantics] Fielding, R., Ed., Gettys, J.,		[draft-ietf-httpbis-p2-semantics] Fielding, R., Ed. and J. Reschke,
	Mogul, J., Frystyk, H., Masinter,		Ed., "Hypertext Transfer Protocol
	L., Leach, P., Berners-Lee, T.,		(HTTP/1.1): Semantics and
	Lafon, Y., Ed., and J. Reschke,		Content",
	Ed., "HTTP/1.1, part 2: Message		draft-ietf-httpbis-p2-semantics-22
	Semantics",		(work in progress), February 2013.
	draft-ietf-httpbis-p2-semantics-18
	(work in progress), January 2012.
	[draft-ietf-httpbis-p6-cache] Fielding, R., Ed., Gettys, J.,		[draft-ietf-httpbis-p6-cache] Fielding, R., Ed., Nottingham, M.,
	Mogul, J., Frystyk, H., Masinter,
	L., Leach, P., Berners-Lee, T.,
	Lafon, Y., Ed., Nottingham, M.,
	Ed., and J. Reschke, Ed.,		Ed., and J. Reschke, Ed.,
	"HTTP/1.1, part 6: Caching",		"Hypertext Transfer Protocol
	draft-ietf-httpbis-p6-cache-18		(HTTP/1.1): Caching",
	(work in progress), January 2012.		draft-ietf-httpbis-p6-cache-22
			(work in progress), February 2013.
			8.2. Informative References
			[HTML] Raggett, D., Le Hors, A., and I.
			Jacobs, "HTML 4.01 Specification",
			W3C Recommendation REC-html401-
			19991224, December 1999, <http://
			www.w3.org/TR/1999/
			REC-html401-19991224>.
			Latest version available at
			<http://www.w3.org/TR/html401>.
			URIs
	[1] <mailto:ietf-http-wg@w3.org>		[1] <mailto:ietf-http-wg@w3.org>
	[2] <mailto:ietf-http-wg-request@w3.org?subject=subscribe>		[2] <mailto:ietf-http-wg-request@w3.org?subject=subscribe>
	Appendix A. Implementations (to be removed by RFC Editor before		Appendix A. Implementations (to be removed by RFC Editor before
	publication)		publication)
	Chrome: Feature requested in Chromium Issue 109012		Chrome: Feature requested in Chromium Issue 109012
	(<http://code.google.com/p/chromium/issues/detail?id=109012>).		(<http://code.google.com/p/chromium/issues/detail?id=109012>).
	Curl (the library): no change was needed (test case:		Curl (the library): no change was needed (test case:
	<https://github.com/bagder/curl/blob/master/tests/data/test1325>).		<https://github.com/bagder/curl/blob/master/tests/data/test1325>).
	Firefox: Feature requested in Bugzilla bug 714302		Firefox: implemented as of Firefox 14 (see
	(<https://bugzilla.mozilla.org/show_bug.cgi?id=714302>), patch		<https://bugzilla.mozilla.org/show_bug.cgi?id=714302>).
	available.
	Safari: automatically redirects 3xx status codes when a Location		Safari: automatically redirects 3xx status codes when a Location
	header field is present, but does not preserve the request method.		header field is present, but does not preserve the request method.
	Appendix B. Change Log (to be removed by RFC Editor before publication)		Appendix B. Change Log (to be removed by RFC Editor before publication)
	B.1. Since draft-reschke-http-status-308-00		B.1. Since draft-reschke-http-status-308-00
	Updated HTTPbis reference. Added Appendix A. Added and resolved		Updated HTTPbis reference. Added Appendix A. Added and resolved
	issue "refresh".		issue "refresh".
	skipping to change at page 7, line 20		skipping to change at page 8, line 5
	B.4. Since draft-reschke-http-status-308-03		B.4. Since draft-reschke-http-status-308-03
	Added and resolved issue "uaconfirm".		Added and resolved issue "uaconfirm".
	B.5. Since draft-reschke-http-status-308-04		B.5. Since draft-reschke-http-status-308-04
	Added and resolved issue "missingconsiderations". Added request		Added and resolved issue "missingconsiderations". Added request
	message to example. Updated the Safari implementation note.		message to example. Updated the Safari implementation note.
	Appendix C. Resolved issues (to be removed by RFC Editor before		B.6. Since draft-reschke-http-status-308-05
	publication)
	Issues that were either rejected or resolved in this version of this
	document.
	C.1. missingconsiderations		Add informative HTML reference. Update HTTPbis references.
	In Section 3:		B.7. Since draft-reschke-http-status-308-06
	Type: change		Added and resolved issues "consistency307" and "sniffing". Updated
			Firefox implementation status.
	stpeter@stpeter.im (2012-02-10): According to HTTPbis Part 2, need to		B.8. Since draft-reschke-http-status-308-07
	explain the request conditions, interactions with response headers,
	and implications for caches. If certain default behavior is assumed,
	it would be good to make that explicit.
	Resolution (2012-02-13): Added missing caching considerations.		Update HTTPbis references. Update Firefox implementation status.
	Appendix D. Open issues (to be removed by RFC Editor prior to		Appendix C. Open issues (to be removed by RFC Editor prior to
	publication)		publication)
	D.1. edit		C.1. edit
	Type: edit		Type: edit
	julian.reschke@greenbytes.de (2011-04-15): Umbrella issue for		julian.reschke@greenbytes.de (2011-04-15): Umbrella issue for
	editorial fixes/enhancements.		editorial fixes/enhancements.
	Author's Address		Author's Address
	Julian F. Reschke		Julian F. Reschke
	greenbytes GmbH		greenbytes GmbH
End of changes. 35 change blocks.
	72 lines changed or deleted		88 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/