draft-ietf-httpbis-p5-range-22.txt		draft-ietf-httpbis-p5-range-latest.txt
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis Working Group R. Fielding, Ed.
	Internet-Draft Adobe		Internet-Draft Adobe
	Obsoletes: 2616 (if approved) Y. Lafon, Ed.		Obsoletes: 2616 (if approved) Y. Lafon, Ed.
	Intended status: Standards Track W3C		Intended status: Standards Track W3C
	Expires: August 27, 2013 J. Reschke, Ed.		Expires: November 17, 2013 J. Reschke, Ed.
	greenbytes		greenbytes
	February 23, 2013		May 16, 2013
	Hypertext Transfer Protocol (HTTP/1.1): Range Requests		Hypertext Transfer Protocol (HTTP/1.1): Range Requests
	draft-ietf-httpbis-p5-range-22		draft-ietf-httpbis-p5-range-latest
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	protocol for distributed, collaborative, hypertext information		protocol for distributed, collaborative, hypertext information
	systems. This document defines range requests and the rules for		systems. This document defines range requests and the rules for
	constructing and combining responses to those requests.		constructing and combining responses to those requests.
	Editorial Note (To be removed by RFC Editor)		Editorial Note (To be removed by RFC Editor)
	Discussion of this draft takes place on the HTTPBIS working group		Discussion of this draft takes place on the HTTPBIS working group
	mailing list (ietf-http-wg@w3.org), which is archived at		mailing list (ietf-http-wg@w3.org), which is archived at
	<http://lists.w3.org/Archives/Public/ietf-http-wg/>.		<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
	The current issues list is at		The current issues list is at
	<http://tools.ietf.org/wg/httpbis/trac/report/3> and related		<http://tools.ietf.org/wg/httpbis/trac/report/3> and related
	documents (including fancy diffs) can be found at		documents (including fancy diffs) can be found at
	<http://tools.ietf.org/wg/httpbis/>.		<http://tools.ietf.org/wg/httpbis/>.
	The changes in this draft are summarized in Appendix E.3.		The changes in this draft are summarized in Appendix E.4.
	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 August 27, 2013.		This Internet-Draft will expire on November 17, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 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
	skipping to change at page 3, line 43		skipping to change at page 3, line 43
	8.2. Informative References . . . . . . . . . . . . . . . . . . 18		8.2. Informative References . . . . . . . . . . . . . . . . . . 18
	Appendix A. Internet Media Type multipart/byteranges . . . . . . 18		Appendix A. Internet Media Type multipart/byteranges . . . . . . 18
	Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 20		Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 20
	Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 21		Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 21
	Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 21		Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 21
	Appendix E. Change Log (to be removed by RFC Editor before		Appendix E. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 23		publication) . . . . . . . . . . . . . . . . . . . . 23
	E.1. Since draft-ietf-httpbis-p5-range-19 . . . . . . . . . . . 23		E.1. Since draft-ietf-httpbis-p5-range-19 . . . . . . . . . . . 23
	E.2. Since draft-ietf-httpbis-p5-range-20 . . . . . . . . . . . 23		E.2. Since draft-ietf-httpbis-p5-range-20 . . . . . . . . . . . 23
	E.3. Since draft-ietf-httpbis-p5-range-21 . . . . . . . . . . . 23		E.3. Since draft-ietf-httpbis-p5-range-21 . . . . . . . . . . . 23
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23		E.4. Since draft-ietf-httpbis-p5-range-22 . . . . . . . . . . . 24
			Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
	1. Introduction		1. Introduction
	Hypertext Transfer Protocol (HTTP) clients often encounter		Hypertext Transfer Protocol (HTTP) clients often encounter
	interrupted data transfers as a result of canceled requests or		interrupted data transfers as a result of canceled requests or
	dropped connections. When a client has stored a partial		dropped connections. When a client has stored a partial
	representation, it is desirable to request the remainder of that		representation, it is desirable to request the remainder of that
	representation in a subsequent request rather than transfer the		representation in a subsequent request rather than transfer the
	entire representation. Likewise, devices with limited local storage		entire representation. Likewise, devices with limited local storage
	might benefit from being able to request only a subset of a larger		might benefit from being able to request only a subset of a larger
	representation, such as a single page of a very large document, or		representation, such as a single page of a very large document, or
	the dimensions of an embedded image.		the dimensions of an embedded image.
	This document defines HTTP/1.1 range requests, partial responses, and		This document defines HTTP/1.1 range requests, partial responses, and
	the multipart/byteranges media type, obsoleting those parts		the multipart/byteranges media type. Range requests are an OPTIONAL
	previously defined in [RFC2616]. Range requests are an OPTIONAL
	feature of HTTP, designed so that recipients not implementing this		feature of HTTP, designed so that recipients not implementing this
	feature (or not supporting it for the target resource) can respond as		feature (or not supporting it for the target resource) can respond as
	if it is a normal GET request without impacting interoperability.		if it is a normal GET request without impacting interoperability.
	Partial responses are indicated by a distinct status code to not be		Partial responses are indicated by a distinct status code to not be
	mistaken for full responses by caches that might not implement the		mistaken for full responses by caches that might not implement the
	feature.		feature.
	Although the range request mechanism is designed to allow for		Although the range request mechanism is designed to allow for
	extensible range types, this specification only defines requests for		extensible range types, this specification only defines requests for
	byte ranges.		byte ranges.
	skipping to change at page 6, line 16		skipping to change at page 6, line 15
	value of last-byte-pos with a value that is one less than the current		value of last-byte-pos with a value that is one less than the current
	length of the selected representation).		length of the selected representation).
	A client can request the last N bytes of the selected representation		A client can request the last N bytes of the selected representation
	using a suffix-byte-range-spec.		using a suffix-byte-range-spec.
	suffix-byte-range-spec = "-" suffix-length		suffix-byte-range-spec = "-" suffix-length
	suffix-length = 1*DIGIT		suffix-length = 1*DIGIT
	If the selected representation is shorter than the specified suffix-		If the selected representation is shorter than the specified suffix-
	length, the entire representation is used. For example (assuming a		length, the entire representation is used.
	representation of length 10000):
			Additional examples, assuming a representation of length 10000:
	o The final 500 bytes (byte offsets 9500-9999, inclusive):		o The final 500 bytes (byte offsets 9500-9999, inclusive):
	bytes=-500		bytes=-500
	Or:		Or:
	bytes=9500-		bytes=9500-
	o The first and last bytes only (bytes 0 and 9999):		o The first and last bytes only (bytes 0 and 9999):
	skipping to change at page 10, line 9		skipping to change at page 10, line 9
	resource, then the server SHOULD process the Range header field as		resource, then the server SHOULD process the Range header field as
	requested. If the validator does not match, then the server MUST		requested. If the validator does not match, then the server MUST
	ignore the Range header field.		ignore the Range header field.
	4. Responses to a Range Request		4. Responses to a Range Request
	4.1. 206 Partial Content		4.1. 206 Partial Content
	The 206 (Partial Content) status code indicates that the server is		The 206 (Partial Content) status code indicates that the server is
	successfully fulfilling a range request for the target resource by		successfully fulfilling a range request for the target resource by
	transferring one or more parts of the selected representation that		transferring one or more parts of the selected representation that
	correspond to the satisfiable ranges found in the requests's Range		correspond to the satisfiable ranges found in the request's Range
	header field (Section 3.1).		header field (Section 3.1).
	If a single part is being transferred, the server generating the 206		If a single part is being transferred, the server generating the 206
	response MUST generate a Content-Range header field, describing what		response MUST generate a Content-Range header field, describing what
	range of the selected representation is enclosed, and a payload		range of the selected representation is enclosed, and a payload
	consisting of the range. For example:		consisting of the range. For example:
	HTTP/1.1 206 Partial Content		HTTP/1.1 206 Partial Content
	Date: Wed, 15 Nov 1995 06:25:24 GMT		Date: Wed, 15 Nov 1995 06:25:24 GMT
	Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT		Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
	skipping to change at page 15, line 26		skipping to change at page 15, line 26
	For byte ranges, failing to overlap the current extent means that the		For byte ranges, failing to overlap the current extent means that the
	first-byte-pos of all of the byte-range-spec values were greater than		first-byte-pos of all of the byte-range-spec values were greater than
	the current length of the selected representation. When this status		the current length of the selected representation. When this status
	code is generated in response to a byte range request, the sender		code is generated in response to a byte range request, the sender
	SHOULD generate a Content-Range header field specifying the current		SHOULD generate a Content-Range header field specifying the current
	length of the selected representation (Section 4.2).		length of the selected representation (Section 4.2).
	For example:		For example:
	HTTP/1.1 416 Range Not Satisfiable		HTTP/1.1 416 Range Not Satisfiable
	Date: Mon, 20 Jan 2012 15:41:54 GMT		Date: Fri, 20 Jan 2012 15:41:54 GMT
	Content-Range: bytes */47022		Content-Range: bytes */47022
	Note: Because servers are free to ignore Range, many		Note: Because servers are free to ignore Range, many
	implementations will simply respond with 200 (OK) if the requested		implementations will simply respond with the entire selected
	ranges are invalid or not satisfiable. That is partly because		representation in a 200 (OK) response if the requested ranges are
	most clients are prepared to receive a 200 (OK) to complete the		invalid or not satisfiable. That is partly because most clients
	task (albeit less efficiently) and partly because clients might		are prepared to receive a 200 (OK) to complete the task (albeit
	not stop making an invalid partial request until they have		less efficiently) and partly because clients might not stop making
	received a complete representation. Thus, clients cannot depend		an invalid partial request until they have received a complete
	on receiving a 416 (Range Not Satisfiable) response even when it		representation. Thus, clients cannot depend on receiving a 416
	is most appropriate.		(Range Not Satisfiable) response even when it is most appropriate.
	5. IANA Considerations		5. IANA Considerations
	5.1. Range Unit Registry		5.1. Range Unit Registry
	The HTTP Range Unit Registry defines the name space for the range		The HTTP Range Unit Registry defines the name space for the range
	unit names and refers to their corresponding specifications. The		unit names and refers to their corresponding specifications. The
	registry is maintained at		registry will be created and maintained at
	<http://www.iana.org/assignments/http-parameters>.		<http://www.iana.org/assignments/http-parameters>.
	5.1.1. Procedure		5.1.1. Procedure
	Registration of an HTTP Range Unit MUST include the following fields:		Registration of an HTTP Range Unit MUST include the following fields:
	o Name		o Name
	o Description		o Description
	skipping to change at page 16, line 46		skipping to change at page 16, line 46
	+-------+-----------------------+-------------+		+-------+-----------------------+-------------+
	| Value | Description | Reference |		| Value | Description | Reference |
	+-------+-----------------------+-------------+		+-------+-----------------------+-------------+
	| 206 | Partial Content | Section 4.1 |		| 206 | Partial Content | Section 4.1 |
	| 416 | Range Not Satisfiable | Section 4.4 |		| 416 | Range Not Satisfiable | Section 4.4 |
	+-------+-----------------------+-------------+		+-------+-----------------------+-------------+
	5.3. Header Field Registration		5.3. Header Field Registration
	The Message Header Field Registry located at <http://www.iana.org/		HTTP header fields are registered within the Message Header Field
	assignments/message-headers/message-header-index.html> shall be		Registry maintained at <http://www.iana.org/assignments/
	updated with the permanent registrations below (see [BCP90]):		message-headers/message-header-index.html>.
			This document defines the following HTTP header fields, so their
			associated registry entries shall be updated according to the
			permanent registrations below (see [BCP90]):
	+-------------------+----------+----------+-------------+		+-------------------+----------+----------+-------------+
	| Header Field Name | Protocol | Status | Reference |		| Header Field Name | Protocol | Status | Reference |
	+-------------------+----------+----------+-------------+		+-------------------+----------+----------+-------------+
	| Accept-Ranges | http | standard | Section 2.3 |		| Accept-Ranges | http | standard | Section 2.3 |
	| Content-Range | http | standard | Section 4.2 |		| Content-Range | http | standard | Section 4.2 |
	| If-Range | http | standard | Section 3.2 |		| If-Range | http | standard | Section 3.2 |
	| Range | http | standard | Section 3.1 |		| Range | http | standard | Section 3.1 |
	+-------------------+----------+----------+-------------+		+-------------------+----------+----------+-------------+
	skipping to change at page 17, line 47		skipping to change at page 17, line 47
	7. Acknowledgments		7. Acknowledgments
	See Section 9 of [Part1].		See Section 9 of [Part1].
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Message Syntax and Routing",		Protocol (HTTP/1.1): Message Syntax and Routing",
	draft-ietf-httpbis-p1-messaging-22 (work in progress),		draft-ietf-httpbis-p1-messaging-latest (work in progress),
	February 2013.		May 2013.
	[Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Semantics and Content",		Protocol (HTTP/1.1): Semantics and Content",
	draft-ietf-httpbis-p2-semantics-22 (work in progress),		draft-ietf-httpbis-p2-semantics-latest (work in progress),
	February 2013.		May 2013.
	[Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Conditional Requests",		Protocol (HTTP/1.1): Conditional Requests",
	draft-ietf-httpbis-p4-conditional-22 (work in progress),		draft-ietf-httpbis-p4-conditional-latest (work in
	February 2013.		progress), May 2013.
	[Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		[Part6] 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",
	draft-ietf-httpbis-p6-cache-22 (work in progress),		draft-ietf-httpbis-p6-cache-latest (work in progress),
	February 2013.		May 2013.
	[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part Two: Media Types", RFC 2046,		Extensions (MIME) Part Two: Media Types", RFC 2046,
	November 1996.		November 1996.
	[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.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234, January 2008.		Specifications: ABNF", STD 68, RFC 5234, January 2008.
	skipping to change at page 19, line 45		skipping to change at page 19, line 45
	Macintosh file type code(s): none		Macintosh file type code(s): none
	Person and email address to contact for further information: See		Person and email address to contact for further information: See
	Authors Section.		Authors Section.
	Intended usage: COMMON		Intended usage: COMMON
	Restrictions on usage: none		Restrictions on usage: none
	Author/Change controller: IESG		Author: See Authors Section.
			Change controller: IESG
	Implementation Notes:		Implementation Notes:
	1. Additional CRLFs might precede the first boundary string in the		1. Additional CRLFs might precede the first boundary string in the
	body.		body.
	2. Although [RFC2046] permits the boundary string to be quoted, some		2. Although [RFC2046] permits the boundary string to be quoted, some
	existing implementations handle a quoted boundary string		existing implementations handle a quoted boundary string
	incorrectly.		incorrectly.
	skipping to change at page 22, line 4		skipping to change at page 21, line 28
	OWS = <OWS, defined in [Part1], Section 3.2.3>		OWS = <OWS, defined in [Part1], Section 3.2.3>
	token = <token, defined in [Part1], Section 3.2.6>		token = <token, defined in [Part1], Section 3.2.6>
	The rules below are defined in other parts:		The rules below are defined in other parts:
	HTTP-date = <HTTP-date, defined in [Part2], Section 7.1.1.1>		HTTP-date = <HTTP-date, defined in [Part2], Section 7.1.1.1>
	entity-tag = <entity-tag, defined in [Part4], Section 2.3>		entity-tag = <entity-tag, defined in [Part4], Section 2.3>
	Appendix D. Collected ABNF		Appendix D. Collected ABNF
			In the collected ABNF below, list rules are expanded as per Section
			1.2 of [Part1].
	Accept-Ranges = acceptable-ranges		Accept-Ranges = acceptable-ranges
	Content-Range = byte-content-range / other-content-range		Content-Range = byte-content-range / other-content-range
	HTTP-date = <HTTP-date, defined in [Part2], Section 7.1.1.1>		HTTP-date = <HTTP-date, defined in [Part2], Section 7.1.1.1>
	If-Range = entity-tag / HTTP-date		If-Range = entity-tag / HTTP-date
	OWS = <OWS, defined in [Part1], Section 3.2.3>		OWS = <OWS, defined in [Part1], Section 3.2.3>
	skipping to change at page 23, line 49		skipping to change at page 23, line 49
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/175>: "Security		o <http://tools.ietf.org/wg/httpbis/trac/ticket/175>: "Security
	consideration: range flooding"		consideration: range flooding"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/223>: "Allowing		o <http://tools.ietf.org/wg/httpbis/trac/ticket/223>: "Allowing
	heuristic caching for new status codes"		heuristic caching for new status codes"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/311>: "Add		o <http://tools.ietf.org/wg/httpbis/trac/ticket/311>: "Add
	limitations to Range to reduce its use as a denial-of-service		limitations to Range to reduce its use as a denial-of-service
	tool"		tool"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/407>: "416 and
			multipart/byteranges"
			E.4. Since draft-ietf-httpbis-p5-range-22
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/436>: "explain list
			expansion in ABNF appendices"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/437>: "incorrect
			example dates"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/438>: "media type
			registration template issues"
	Index		Index
	2		2
	206 Partial Content (status code) 10		206 Partial Content (status code) 10
	4		4
	416 Range Not Satisfiable (status code) 15		416 Range Not Satisfiable (status code) 15
	A		A
	Accept-Ranges header field 7		Accept-Ranges header field 7
End of changes. 20 change blocks.
	33 lines changed or deleted		60 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/