draft-ietf-httpbis-p5-range-21.txt		draft-ietf-httpbis-p5-range-22.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: April 7, 2013 J. Reschke, Ed.		Expires: August 27, 2013 J. Reschke, Ed.
	greenbytes		greenbytes
	October 4, 2012		February 23, 2013
	Hypertext Transfer Protocol (HTTP/1.1): Range Requests		Hypertext Transfer Protocol (HTTP/1.1): Range Requests
	draft-ietf-httpbis-p5-range-21		draft-ietf-httpbis-p5-range-22
	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.2.		The changes in this draft are summarized in Appendix E.3.
	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 April 7, 2013.		This Internet-Draft will expire on August 27, 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 3, line 11		skipping to change at page 3, line 11
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4		1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4
	1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4		1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
	2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 5		2.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5		2.2. Other Range Units . . . . . . . . . . . . . . . . . . . . 7
	3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 5		2.3. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7
	3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 6		3. Range Requests . . . . . . . . . . . . . . . . . . . . . . . . 7
	4. Responses to a Range Request . . . . . . . . . . . . . . . . . 7		3.1. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	4.1. Response to a Single and Multiple Ranges Request . . . . . 7		3.2. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 9
	4.2. Combining Ranges . . . . . . . . . . . . . . . . . . . . . 7		4. Responses to a Range Request . . . . . . . . . . . . . . . . . 9
	5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 8		4.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 10
	5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 8		4.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 12
	5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 9		4.3. Combining Ranges . . . . . . . . . . . . . . . . . . . . . 14
	5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 10		4.4. 416 Range Not Satisfiable . . . . . . . . . . . . . . . . 15
	5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 11		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 11		5.1. Range Unit Registry . . . . . . . . . . . . . . . . . . . 15
	5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 13		5.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 15
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		5.1.2. Registrations . . . . . . . . . . . . . . . . . . . . 16
	6.1. Status Code Registration . . . . . . . . . . . . . . . . . 14		5.2. Status Code Registration . . . . . . . . . . . . . . . . . 16
	6.2. Header Field Registration . . . . . . . . . . . . . . . . 15		5.3. Header Field Registration . . . . . . . . . . . . . . . . 16
	6.3. Range Specifier Registration . . . . . . . . . . . . . . . 15		6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 15		6.1. Denial of Service Attacks using Range . . . . . . . . . . 17
	7.1. Overlapping Ranges . . . . . . . . . . . . . . . . . . . . 16		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16		8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 16		8.2. Informative References . . . . . . . . . . . . . . . . . . 18
	9.2. Informative References . . . . . . . . . . . . . . . . . . 16		Appendix A. Internet Media Type multipart/byteranges . . . . . . 18
	Appendix A. Internet Media Type multipart/byteranges . . . . . . 17		Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 20
	Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 19		Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 21
	Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 19
	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) . . . . . . . . . . . . . . . . . . . . 22		publication) . . . . . . . . . . . . . . . . . . . . 23
	E.1. Since draft-ietf-httpbis-p5-range-19 . . . . . . . . . . . 22		E.1. Since draft-ietf-httpbis-p5-range-19 . . . . . . . . . . . 23
	E.2. Since draft-ietf-httpbis-p5-range-20 . . . . . . . . . . . 22		E.2. Since draft-ietf-httpbis-p5-range-20 . . . . . . . . . . . 23
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22		E.3. Since draft-ietf-httpbis-p5-range-21 . . . . . . . . . . . 23
			Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	HTTP clients often encounter interrupted data transfers as a result		Hypertext Transfer Protocol (HTTP) clients often encounter
	of canceled requests or dropped connections. When a client has		interrupted data transfers as a result of canceled requests or
	stored a partial representation, it is desirable to request the		dropped connections. When a client has stored a partial
	remainder of that representation in a subsequent request rather than		representation, it is desirable to request the remainder of that
	transfer the entire representation. There are also a number of Web		representation in a subsequent request rather than transfer the
	applications that benefit from being able to request only a subset of		entire representation. Likewise, devices with limited local storage
	a larger representation, such as a single page of a very large		might benefit from being able to request only a subset of a larger
	document or only part of an image to be rendered by a device with		representation, such as a single page of a very large document, or
	limited local storage.		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. The protocol for range requests		the multipart/byteranges media type, obsoleting those parts
	is an OPTIONAL feature of HTTP, designed so resources or recipients		previously defined in [RFC2616]. Range requests are an OPTIONAL
	that do not implement this feature can respond as if it is a normal		feature of HTTP, designed so that recipients not implementing this
	GET request without impacting interoperability. Partial responses		feature (or not supporting it for the target resource) can respond as
	are indicated by a distinct status code to not be mistaken for full		if it is a normal GET request without impacting interoperability.
	responses by intermediate caches that might not implement the		Partial responses are indicated by a distinct status code to not be
			mistaken for full responses by caches that might not implement the
	feature.		feature.
	Although the HTTP 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.
	1.1. Conformance and Error Handling		1.1. Conformance and Error Handling
	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].
	Conformance criteria and considerations regarding error handling are		Conformance criteria and considerations regarding error handling are
	skipping to change at page 4, line 49		skipping to change at page 4, line 50
	1.2. Syntax Notation		1.2. Syntax Notation
	This specification uses the Augmented Backus-Naur Form (ABNF)		This specification uses the Augmented Backus-Naur Form (ABNF)
	notation of [RFC5234] with the list rule extension defined in Section		notation of [RFC5234] with the list rule extension defined in Section
	1.2 of [Part1]. Appendix C describes rules imported from other		1.2 of [Part1]. Appendix C describes rules imported from other
	documents. Appendix D shows the collected ABNF with the list rule		documents. Appendix D shows the collected ABNF with the list rule
	expanded.		expanded.
	2. Range Units		2. Range Units
	HTTP/1.1 allows a client to request that only part (a range) of the		A representation can be partitioned into subranges according to
	representation be included within the response. HTTP/1.1 uses range		various structural units, depending on the structure inherent in the
	units in the Range (Section 5.4) and Content-Range (Section 5.2)		representation's media type. This "range unit" is used in the
	header fields. A representation can be broken down into subranges		Accept-Ranges (Section 2.3) response header field to advertise
	according to various structural units.		support for range requests, the Range (Section 3.1) request header
			field to delineate the parts of a representation that are requested,
			and the Content-Range (Section 4.2) payload header field to describe
			which part of a representation is being transferred.
	range-unit = bytes-unit / other-range-unit		range-unit = bytes-unit / other-range-unit
	bytes-unit = "bytes"
	other-range-unit = token
	HTTP/1.1 has been designed to allow implementations of applications
	that do not depend on knowledge of ranges. The only range unit
	defined by HTTP/1.1 is "bytes". Additional specifiers can be defined
	as described in Section 2.1.
	If a range unit is not understood in a request, a server MUST ignore
	the whole Range header field (Section 5.4). If a range unit is not
	understood in a response, an intermediary SHOULD pass the response to
	the client; a client MUST fail.
	2.1. Range Specifier Registry
	The HTTP Range Specifier Registry defines the name space for the
	range specifier names.
	Registrations MUST include the following fields:
	o Name
	o Description
	o Pointer to specification text
	Values to be added to this name space require IETF Review (see		2.1. Byte Ranges
	[RFC5226], Section 4.1).
	The registry itself is maintained at
	<http://www.iana.org/assignments/http-range-specifiers>.
	3. Status Code Definitions
	3.1. 206 Partial Content
	The server has fulfilled the partial GET request for the resource.		Since representation data is transferred in payloads as a sequence of
	The request MUST have included a Range header field (Section 5.4)		octets, a byte range is a meaningful substructure for any
	indicating the desired range, and MAY have included an If-Range		representation transferable over HTTP (Section 3 of [Part2]). We
	header field (Section 5.3) to make the request conditional.		define the "bytes" range unit for expressing subranges of the data's
			octet sequence.
	The response MUST include the following header fields:		bytes-unit = "bytes"
	o Either a Content-Range header field (Section 5.2) indicating the		A byte range operation MAY specify a single range of bytes, or a set
	range included with this response, or a multipart/byteranges		of ranges within a single representation.
	Content-Type including Content-Range fields for each part. If a
	Content-Length header field is present in the response, its value
	MUST match the actual number of octets transmitted in the message
	body.
	o Date		byte-ranges-specifier = bytes-unit "=" byte-range-set
			byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec )
			byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
			first-byte-pos = 1*DIGIT
			last-byte-pos = 1*DIGIT
	o Cache-Control, ETag, Expires, Content-Location and/or Vary, if the		The first-byte-pos value in a byte-range-spec gives the byte-offset
	header field would have been sent in a 200 (OK) response to the		of the first byte in a range. The last-byte-pos value gives the
	same request		byte-offset of the last byte in the range; that is, the byte
			positions specified are inclusive. Byte offsets start at zero.
	If a 206 is sent in response to a request with an If-Range header		Examples of byte-ranges-specifier values:
	field, it SHOULD NOT include other representation header fields.
	Otherwise, the response MUST include all of the representation header
	fields that would have been returned with a 200 (OK) response to the
	same request.
	Caches MAY use a heuristic (see Section 4.1.2 of [Part6]) to		o The first 500 bytes (byte offsets 0-499, inclusive):
	determine freshness for 206 responses.
	3.2. 416 Requested Range Not Satisfiable		bytes=0-499
	A server SHOULD return a response with this status code if a request		o The second 500 bytes (byte offsets 500-999, inclusive):
	included a Range header field (Section 5.4), and none of the ranges-
	specifier values in this field overlap the current extent of the
	selected resource, and the request did not include an If-Range header
	field (Section 5.3). (For byte-ranges, this means that the first-
	byte-pos of all of the byte-range-spec values were greater than the
	current length of the selected resource.)
	When this status code is returned for a byte-range request, the		bytes=500-999
	response SHOULD include a Content-Range header field specifying the
	current length of the representation (see Section 5.2). This
	response MUST NOT use the multipart/byteranges content-type. For
	example,
	HTTP/1.1 416 Requested Range Not Satisfiable		A byte-range-spec is invalid if the last-byte-pos value is present
	Date: Mon, 20 Jan 2012 15:41:54 GMT		and less than the first-byte-pos.
	Content-Range: bytes */47022
	Content-Type: image/gif
	Note: Clients cannot depend on servers to send a 416 (Requested		A client can limit the number of bytes requested without knowing the
	Range Not Satisfiable) response instead of a 200 (OK) response for		size of the selected representation. If the last-byte-pos value is
	an unsatisfiable Range header field, since not all servers		absent, or if the value is greater than or equal to the current
	implement this header field.		length of the representation data, the byte range is interpreted as
			the remainder of the representation (i.e., the server replaces the
			value of last-byte-pos with a value that is one less than the current
			length of the selected representation).
	4. Responses to a Range Request		A client can request the last N bytes of the selected representation
			using a suffix-byte-range-spec.
	4.1. Response to a Single and Multiple Ranges Request		suffix-byte-range-spec = "-" suffix-length
			suffix-length = 1*DIGIT
	When an HTTP message includes the content of a single range (for		If the selected representation is shorter than the specified suffix-
	example, a response to a request for a single range, or to a request		length, the entire representation is used. For example (assuming a
	for a set of ranges that overlap without any holes), this content is		representation of length 10000):
	transmitted with a Content-Range header field, and a Content-Length
	header field showing the number of bytes actually transferred. For
	example,
	HTTP/1.1 206 Partial Content		o The final 500 bytes (byte offsets 9500-9999, inclusive):
	Date: Wed, 15 Nov 1995 06:25:24 GMT
	Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
	Content-Range: bytes 21010-47021/47022
	Content-Length: 26012
	Content-Type: image/gif
	When an HTTP message includes the content of multiple ranges (for		bytes=-500
	example, a response to a request for multiple non-overlapping
	ranges), these are transmitted as a multipart message. The multipart
	media type used for this purpose is "multipart/byteranges" as defined
	in Appendix A.
	A server MAY combine requested ranges when those ranges are		Or:
	overlapping (see Section 7.1).
	A response to a request for a single range MUST NOT be sent using the		bytes=9500-
	multipart/byteranges media type. A response to a request for
	multiple ranges, whose result is a single range, MAY be sent as a
	multipart/byteranges media type with one part. A client that cannot
	decode a multipart/byteranges message MUST NOT ask for multiple
	ranges in a single request.
	When a client asks for multiple ranges in one request, the server		o The first and last bytes only (bytes 0 and 9999):
	SHOULD return them in the order that they appeared in the request.
	4.2. Combining Ranges		bytes=0-0,-1
	A response might transfer only a subrange of a representation if the		o Other valid (but not canonical) specifications of the second 500
	connection closed prematurely or if the request used one or more		bytes (byte offsets 500-999, inclusive):
	Range specifications. After several such transfers, a client might
	have received several ranges of the same representation. These
	ranges can only be safely combined if they all have in common the
	same strong validator, where "strong validator" is defined to be
	either an entity-tag that is not marked as weak (Section 2.3 of
	[Part4]) or, if no entity-tag is provided, a Last-Modified value that
	is strong in the sense defined by Section 2.2.2 of [Part4].
	When a client receives an incomplete 200 (OK) or 206 (Partial		bytes=500-600,601-999
	Content) response and already has one or more stored responses for		bytes=500-700,601-999
	the same method and effective request URI, all of the stored
	responses with the same strong validator MAY be combined with the
	partial content in this new response. If none of the stored
	responses contain the same strong validator, then this new response
	corresponds to a new representation and MUST NOT be combined with the
	existing stored responses.
	If the new response is an incomplete 200 (OK) response, then the		If a valid byte-range-set includes at least one byte-range-spec with
	header fields of that new response are used for any combined response		a first-byte-pos that is less than the current length of the
	and replace those of the matching stored responses.		representation, or at least one suffix-byte-range-spec with a non-
			zero suffix-length, then the byte-range-set is satisfiable.
			Otherwise, the byte-range-set is unsatisfiable.
	If the new response is a 206 (Partial Content) response and at least		In the byte range syntax, first-byte-pos, last-byte-pos, and suffix-
	one of the matching stored responses is a 200 (OK), then the combined		length are expressed as decimal number of octets. Since there is no
	response header fields consist of the most recent 200 response's		predefined limit to the length of a payload, recipients ought to
	header fields. If all of the matching stored responses are 206		anticipate potentially large decimal numerals and prevent parsing
	responses, then the stored response with the most header fields is		errors due to integer conversion overflows.
	used as the source of header fields for the combined response, except
	that the client MUST use other header fields provided in the new
	response, aside from Content-Range, to replace all instances of the
	corresponding header fields in the stored response.
	The combined response message body consists of the union of partial		2.2. Other Range Units
	content ranges in the new response and each of the selected
	responses. If the union consists of the entire range of the
	representation, then the combined response MUST be recorded as a
	complete 200 (OK) response with a Content-Length header field that
	reflects the complete length. Otherwise, the combined response(s)
	MUST include a Content-Range header field describing the included
	range(s) and be recorded as incomplete. If the union consists of a
	discontinuous range of the representation, then the client MAY store
	it as either a multipart range response or as multiple 206 responses
	with one continuous range each.
	5. Header Field Definitions		Range units are intended to be extensible. New range units ought to
			be registered with IANA, as defined in Section 5.1.
	This section defines the syntax and semantics of HTTP/1.1 header		other-range-unit = token
	fields related to range requests and partial responses.
	5.1. Accept-Ranges		2.3. Accept-Ranges
	The "Accept-Ranges" header field allows a resource to indicate its		The "Accept-Ranges" header field allows a server to indicate that it
	acceptance of range requests.		supports range requests for the target resource.
	Accept-Ranges = acceptable-ranges		Accept-Ranges = acceptable-ranges
	acceptable-ranges = 1#range-unit / "none"		acceptable-ranges = 1#range-unit / "none"
	Origin servers that accept byte-range requests MAY send		Origin servers that support byte-range requests MAY send
	Accept-Ranges: bytes		Accept-Ranges: bytes
	but are not required to do so. Clients MAY generate range requests		but are not required to do so. Clients MAY generate range requests
	without having received this header field for the resource involved.		without having received this header field for the resource involved.
	Range units are defined in Section 2.		Range units are defined in Section 2.
	Servers that do not accept any kind of range request for a resource		Servers that do not support any kind of range request for the target
	MAY send		resource resource MAY send
	Accept-Ranges: none		Accept-Ranges: none
	to advise the client not to attempt a range request.		to advise the client not to attempt a range request.
	5.2. Content-Range		3. Range Requests
	The "Content-Range" header field is sent with a partial
	representation to specify where in the full representation the
	payload body is intended to be applied.
	Range units are defined in Section 2.
	Content-Range = byte-content-range-spec
	/ other-content-range-spec
	byte-content-range-spec = bytes-unit SP
	byte-range-resp-spec "/"
	( instance-length / "*" )
	byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)
	/ "*"
	instance-length = 1*DIGIT
	other-content-range-spec = other-range-unit SP
	other-range-resp-spec
	other-range-resp-spec = *CHAR
	The header field SHOULD indicate the total length of the full
	representation, unless this length is unknown or difficult to
	determine. The asterisk "*" character means that the instance-length
	is unknown at the time when the response was generated.
	Unlike byte-ranges-specifier values (see Section 5.4.1), a byte-
	range-resp-spec MUST only specify one range, and MUST contain
	absolute byte positions for both the first and last byte of the
	range.
	A byte-content-range-spec with a byte-range-resp-spec whose last-
	byte-pos value is less than its first-byte-pos value, or whose
	instance-length value is less than or equal to its last-byte-pos
	value, is invalid. The recipient of an invalid byte-content-range-
	spec MUST ignore it and any content transferred along with it.
	In the case of a byte range request: A server sending a response with
	status code 416 (Requested Range Not Satisfiable) SHOULD include a
	Content-Range field with a byte-range-resp-spec of "*". The
	instance-length specifies the current length of the selected
	resource. A response with status code 206 (Partial Content) MUST NOT
	include a Content-Range field with a byte-range-resp-spec of "*".
	The "Content-Range" header field has no meaning for status codes that		3.1. Range
	do not explicitly describe its semantic. Currently, only status
	codes 206 (Partial Content) and 416 (Requested Range Not Satisfiable)
	describe the meaning of this header field.
	Examples of byte-content-range-spec values, assuming that the		The "Range" header field on a GET request modifies the method
	representation contains a total of 1234 bytes:		semantics to request transfer of only one or more subranges of the
			selected representation data, rather than the entire selected
			representation data.
	o The first 500 bytes:		Range = byte-ranges-specifier / other-ranges-specifier
			other-ranges-specifier = other-range-unit "=" other-range-set
			other-range-set = 1*CHAR
	bytes 0-499/1234		A server MAY ignore the Range header field. However, origin servers
			and intermediate caches ought to support byte ranges when possible,
			since Range supports efficient recovery from partially failed
			transfers and partial retrieval of large representations. A server
			MUST ignore a Range header field received with a request method other
			than GET.
	o The second 500 bytes:		An origin server MUST ignore a Range header field that contains a
			range unit it does not understand. A proxy MAY either discard a
			Range header field that contains a range unit it does not understand
			or pass it to the next inbound server when forwarding the request.
	bytes 500-999/1234		A server that supports range requests ought to ignore or reject a
			Range header field that consists of more than two overlapping ranges,
			or a set of many small ranges that are not listed in ascending order,
			since both are indications of either a broken client or a deliberate
			denial of service attack (Section 6.1). A client SHOULD NOT request
			multiple ranges that are inherently less efficient to process and
			transfer than a single range that encompasses the same data.
	o All except for the first 500 bytes:		A client that is requesting multiple ranges SHOULD list those ranges
			in ascending order (the order in which they would typically be
			received in a complete representation) unless there is a specific
			need to request a later part earlier. For example, a user agent
			processing a large representation with an internal catalog of parts
			might need to request later parts first, particularly if the
			representation consists of pages stored in reverse order and the user
			agent wishes to transfer one page at a time.
	bytes 500-1233/1234		The Range header field is evaluated after evaluating the
			preconditions of [Part4] and only if the result of their evaluation
			is leading toward a 200 (OK) response. In other words, Range is
			ignored when a conditional GET would result in a 304 (Not Modified)
			response.
	o The last 500 bytes:		The If-Range header field (Section 3.2) can be used as a precondition
			to applying the Range header field.
	bytes 734-1233/1234		If all of the preconditions are true, the server supports the Range
			header field for the target resource, and the specified range(s) are
			valid and satisfiable (as defined in Section 2.1), the server SHOULD
			send a 206 (Partial Content) response with a payload containing one
			or more partial representations that correspond to the satisfiable
			ranges requested, as defined in Section 4.
	If the server ignores a byte-range-spec (for example if it is		If all of the preconditions are true, the server supports the Range
	syntactically invalid, or if it might be seen as a denial-of-service		header field for the target resource, and the specified range(s) are
	attack), the server SHOULD treat the request as if the invalid Range		invalid or unsatisfiable, the server SHOULD send a 416 (Range Not
	header field did not exist. (Normally, this means return a 200 (OK)		Satisfiable) response.
	response containing the full representation).
	5.3. If-Range		3.2. If-Range
	If a client has a partial copy of a representation and wishes to have		If a client has a partial copy of a representation and wishes to have
	an up-to-date copy of the entire representation, it could use the		an up-to-date copy of the entire representation, it could use the
	Range header field with a conditional GET (using either or both of		Range header field with a conditional GET (using either or both of
	If-Unmodified-Since and If-Match.) However, if the condition fails		If-Unmodified-Since and If-Match.) However, if the condition fails
	because the representation has been modified, the client would then		because the representation has been modified, the client would then
	have to make a second request to obtain the entire current		have to make a second request to obtain the entire current
	representation.		representation.
	The "If-Range" header field allows a client to "short-circuit" the		The "If-Range" header field allows a client to "short-circuit" the
	second request. Informally, its meaning is "if the representation is		second request. Informally, its meaning is: if the representation is
	unchanged, send me the part(s) that I am missing; otherwise, send me		unchanged, send me the part(s) that I am requesting in Range;
	the entire new representation".		otherwise, send me the entire representation.
	If-Range = entity-tag / HTTP-date		If-Range = entity-tag / HTTP-date
	Clients MUST NOT use an entity-tag marked as weak in an If-Range		Clients MUST NOT use an entity-tag marked as weak in an If-Range
	field value and MUST NOT use a Last-Modified date in an If-Range		field value and MUST NOT use a Last-Modified date in an If-Range
	field value unless it has no entity-tag for the representation and		field value unless it has no entity-tag for the representation and
	the Last-Modified date it does have for the representation is strong		the Last-Modified date it does have for the representation is strong
	in the sense defined by Section 2.2.2 of [Part4].		in the sense defined by Section 2.2.2 of [Part4].
	A server that evaluates a conditional range request that is		A server that evaluates a conditional range request that is
	applicable to one of its representations MUST evaluate the condition		applicable to one of its representations MUST evaluate the condition
	as false if the entity-tag used as a validator is marked as weak or,		as false if the entity-tag used as a validator is marked as weak or,
	when an HTTP-date is used as the validator, if the date value is not		when an HTTP-date is used as the validator, if the date value is not
	strong in the sense defined by Section 2.2.2 of [Part4]. (A server		strong in the sense defined by Section 2.2.2 of [Part4]. (A server
	can distinguish between a valid HTTP-date and any form of entity-tag		can distinguish between a valid HTTP-date and any form of entity-tag
	by examining the first two characters.)		by examining the first two characters.)
	The If-Range header field SHOULD only be sent by clients together		A client MUST NOT generate an If-Range header field in a request that
	with a Range header field. The If-Range header field MUST be ignored		does not contain a Range header field. A server MUST ignore an If-
	if it is received in a request that does not include a Range header		Range header field received in a request that does not contain a
	field. The If-Range header field MUST be ignored by a server that		Range header field. An origin server MUST ignore an If-Range header
	does not support the sub-range operation.		field received in a request for a target resource that does not
			support Range requests.
	If the validator given in the If-Range header field matches the		If the validator given in the If-Range header field matches the
	current validator for the selected representation of the target		current validator for the selected representation of the target
	resource, then the server SHOULD send the specified sub-range of the		resource, then the server SHOULD process the Range header field as
	representation using a 206 (Partial Content) response. If the		requested. If the validator does not match, then the server MUST
	validator does not match, then the server SHOULD send the entire		ignore the Range header field.
	representation using a 200 (OK) response.
	5.4. Range		4. Responses to a Range Request
			4.1. 206 Partial Content
	5.4.1. Byte Ranges		The 206 (Partial Content) status code indicates that the server is
			successfully fulfilling a range request for the target resource by
			transferring one or more parts of the selected representation that
			correspond to the satisfiable ranges found in the requests's Range
			header field (Section 3.1).
	Since all HTTP representations are transferred as sequences of bytes,		If a single part is being transferred, the server generating the 206
	the concept of a byte range is meaningful for any HTTP		response MUST generate a Content-Range header field, describing what
	representation. (However, not all clients and servers need to		range of the selected representation is enclosed, and a payload
	support byte-range operations.)		consisting of the range. For example:
	Byte range specifications in HTTP apply to the sequence of bytes in
	the representation data (not necessarily the same as the message
	body).
	A byte range operation MAY specify a single range of bytes, or a set		HTTP/1.1 206 Partial Content
	of ranges within a single representation.		Date: Wed, 15 Nov 1995 06:25:24 GMT
			Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
			Content-Range: bytes 21010-47021/47022
			Content-Length: 26012
			Content-Type: image/gif
	byte-ranges-specifier = bytes-unit "=" byte-range-set		... 26012 bytes of partial image data ...
	byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec )
	byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
	first-byte-pos = 1*DIGIT
	last-byte-pos = 1*DIGIT
	The first-byte-pos value in a byte-range-spec gives the byte-offset		If multiple parts are being transferred, the server generating the
	of the first byte in a range. The last-byte-pos value gives the		206 response MUST generate a "multipart/byteranges" payload, as
	byte-offset of the last byte in the range; that is, the byte		defined in Appendix A, and a Content-Type header field containing the
	positions specified are inclusive. Byte offsets start at zero.		multipart/byteranges media type and its required boundary parameter.
			To avoid confusion with single part responses, a server MUST NOT
			generate a Content-Range header field in the HTTP header block of a
			multiple part response (this field will be sent in each part
			instead).
	If the last-byte-pos value is present, it MUST be greater than or		Within the header area of each body part in the multipart payload,
	equal to the first-byte-pos in that byte-range-spec, or the byte-		the server MUST generate a Content-Range header field corresponding
	range-spec is syntactically invalid. The recipient of a byte-range-		to the range being enclosed in that body part. If the selected
	set that includes one or more syntactically invalid byte-range-spec		representation would have had a Content-Type header field in a 200
	values MUST ignore the header field that includes that byte-range-		(OK) response, the server SHOULD generate that same Content-Type
	set.		field in the header area of each body part. For example:
	If the last-byte-pos value is absent, or if the value is greater than		HTTP/1.1 206 Partial Content
	or equal to the current length of the representation data, last-byte-		Date: Wed, 15 Nov 1995 06:25:24 GMT
	pos is taken to be equal to one less than the current length of the		Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
	representation in bytes.		Content-Length: 1741
			Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
	By its choice of last-byte-pos, a client can limit the number of		--THIS_STRING_SEPARATES
	bytes retrieved without knowing the size of the representation.		Content-Type: application/pdf
			Content-Range: bytes 500-999/8000
	suffix-byte-range-spec = "-" suffix-length		...the first range...
	suffix-length = 1*DIGIT		--THIS_STRING_SEPARATES
			Content-Type: application/pdf
			Content-Range: bytes 7000-7999/8000
	A suffix-byte-range-spec is used to specify the suffix of the		...the second range
	representation data, of a length given by the suffix-length value.		--THIS_STRING_SEPARATES--
	(That is, this form specifies the last N bytes of a representation.)
	If the representation is shorter than the specified suffix-length,
	the entire representation is used.
	If a syntactically valid byte-range-set includes at least one byte-		When multiple ranges are requested, a server MAY coalesce any of the
	range-spec whose first-byte-pos is less than the current length of		ranges that overlap or that are separated by a gap that is smaller
	the representation, or at least one suffix-byte-range-spec with a		than the overhead of sending multiple parts, regardless of the order
	non-zero suffix-length, then the byte-range-set is satisfiable.		in which the corresponding byte-range-spec appeared in the received
	Otherwise, the byte-range-set is unsatisfiable. If the byte-range-		Range header field. Since the typical overhead between parts of a
	set is unsatisfiable, the server SHOULD return a response with a 416		multipart/byteranges payload is around 80 bytes, depending on the
	(Requested Range Not Satisfiable) status code. Otherwise, the server		selected representation's media type and the chosen boundary
	SHOULD return a response with a 206 (Partial Content) status code		parameter length, it can be less efficient to transfer many small
	containing the satisfiable ranges of the representation.		disjoint parts than it is to transfer the entire selected
			representation.
	In the byte range syntax, first-byte-pos, last-byte-pos, and suffix-		A server MUST NOT generate a multipart response to a request for a
	length are expressed as decimal number of octets. Since there is no		single range, since a client that does not request multiple parts
	predefined limit to the length of an HTTP payload, recipients SHOULD		might not support multipart responses. However, a server MAY
	anticipate potentially large decimal numerals and prevent parsing		generate a multipart/byteranges payload with only a single body part
	errors due to integer conversion overflows.		if multiple ranges were requested and only one range was found to be
			satisfiable or only one range remained after coalescing. A client
			that cannot process a multipart/byteranges response MUST NOT ask for
			multiple ranges in a single request.
	Examples of byte-ranges-specifier values (assuming a representation		When a multipart response payload is generated, the server SHOULD
	of length 10000):		send the parts in the same order that the corresponding byte-range-
			spec appeared in the received Range header field, excluding those
			ranges that were deemed unsatisfiable or that were coalesced into
			other ranges. A client that receives a multipart response MUST
			inspect the Content-Range header field present in each body part in
			order to determine which range is contained in that body part; a
			client cannot rely on receiving the same ranges that it requested,
			nor the same order that it requested.
	o The first 500 bytes (byte offsets 0-499, inclusive):		When a 206 response is generated, the server MUST generate the
			following header fields, in addition to those required above, if the
			field would have been sent in a 200 (OK) response to the same
			request: Date, Cache-Control, ETag, Expires, Content-Location, and
			Vary.
	bytes=0-499		If a 206 is generated in response to a request with an If-Range
			header field, the sender SHOULD NOT generate other representation
			header fields beyond those required above, because the client is
			understood to already have a prior response containing those header
			fields. Otherwise, the sender MUST generate all of the
			representation header fields that would have been sent in a 200 (OK)
			response to the same request.
	o The second 500 bytes (byte offsets 500-999, inclusive):		A 206 response is cacheable unless otherwise indicated by explicit
			cache controls (see Section 4.1.2 of [Part6]).
	bytes=500-999		4.2. Content-Range
	o The final 500 bytes (byte offsets 9500-9999, inclusive):		The "Content-Range" header field is sent in a single part 206
			(Partial Content) response to indicate the partial range of the
			selected representation enclosed as the message payload, sent in each
			part of a multipart 206 response to indicate the range enclosed
			within each body part, and sent in 416 (Range Not Satisfiable)
			responses to provide information about the selected representation.
	bytes=-500		Content-Range = byte-content-range
			/ other-content-range
	Or:		byte-content-range = bytes-unit SP
			( byte-range-resp / unsatisfied-range )
	bytes=9500-		byte-range-resp = byte-range "/" ( complete-length / "*" )
			byte-range = first-byte-pos "-" last-byte-pos
			unsatisfied-range = "*/" complete-length
	o The first and last bytes only (bytes 0 and 9999):		complete-length = 1*DIGIT
	bytes=0-0,-1		other-content-range = other-range-unit SP other-range-resp
			other-range-resp = *CHAR
	o Several legal but not canonical specifications of the second 500		If a 206 (Partial Content) response contains a Content-Range header
	bytes (byte offsets 500-999, inclusive):		field with a range unit (Section 2) that the recipient does not
			understand, the recipient MUST NOT attempt to recombine it with a
			stored representation. A proxy that receives such a message SHOULD
			forward it downstream.
	bytes=500-600,601-999		For byte ranges, a sender SHOULD indicate the complete length of the
	bytes=500-700,601-999		representation from which the range has been extracted, unless the
			complete length is unknown or difficult to determine. An asterisk
			character ("*") in place of the complete-length indicates that the
			representation length was unknown when the header field was
			generated.
	5.4.2. Range Retrieval Requests		The following example illustrates when the complete length of the
			selected representation is known by the sender to be 1234 bytes:
	The "Range" header field defines the GET method (conditional or not)		Content-Range: bytes 42-1233/1234
	to request one or more sub-ranges of the response representation
	data, instead of the entire representation data.
	Range = byte-ranges-specifier / other-ranges-specifier		and this second example illustrates when the complete length is
	other-ranges-specifier = other-range-unit "=" other-range-set		unknown:
	other-range-set = 1*CHAR
	A server MAY ignore the Range header field. However, origin servers		Content-Range: bytes 42-1233/*
	and intermediate caches ought to support byte ranges when possible,
	since Range supports efficient recovery from partially failed
	transfers, and supports efficient partial retrieval of large
	representations.
	If the server supports the Range header field and the specified range		A Content-Range field value is invalid if it contains a byte-range-
	or ranges are appropriate for the representation:		resp that has a last-byte-pos value less than its first-byte-pos
			value, or a complete-length value less than or equal to its last-
			byte-pos value. The recipient of an invalid Content-Range MUST NOT
			attempt to recombine the received content with a stored
			representation.
	o The presence of a Range header field in an unconditional GET		A server generating a 416 (Range Not Satisfiable) response to a byte
	modifies what is returned if the GET is otherwise successful. In		range request SHOULD send a Content-Range header field with an
	other words, the response carries a status code of 206 (Partial		unsatisfied-range value, as in the following example:
	Content) instead of 200 (OK).
	o The presence of a Range header field in a conditional GET (a		Content-Range: bytes */1234
	request using one or both of If-Modified-Since and If-None-Match,
	or one or both of If-Unmodified-Since and If-Match) modifies what
	is returned if the GET is otherwise successful and the condition
	is true. It does not affect the 304 (Not Modified) response
	returned if the conditional is false.
	In some cases, it might be more appropriate to use the If-Range		The complete-length in a 416 response indicates the current length of
	header field (see Section 5.3) in addition to the Range header field.		the selected representation.
	If a proxy that supports ranges receives a Range request, forwards		The "Content-Range" header field has no meaning for status codes that
	the request to an inbound server, and receives an entire		do not explicitly describe its semantic. For this specification,
	representation in reply, it MAY only return the requested range to		only the 206 (Partial Content) and 416 (Range Not Satisfiable) status
	its client.		codes describe a meaning for Content-Range.
	6. IANA Considerations		The following are examples of Content-Range values in which the
			selected representation contains a total of 1234 bytes:
	6.1. Status Code Registration		o The first 500 bytes:
			Content-Range: bytes 0-499/1234
			o The second 500 bytes:
			Content-Range: bytes 500-999/1234
			o All except for the first 500 bytes:
			Content-Range: bytes 500-1233/1234
			o The last 500 bytes:
			Content-Range: bytes 734-1233/1234
			4.3. Combining Ranges
			A response might transfer only a subrange of a representation if the
			connection closed prematurely or if the request used one or more
			Range specifications. After several such transfers, a client might
			have received several ranges of the same representation. These
			ranges can only be safely combined if they all have in common the
			same strong validator, where "strong validator" is defined to be
			either an entity-tag that is not marked as weak (Section 2.3 of
			[Part4]) or, if no entity-tag is provided, a Last-Modified value that
			is strong in the sense defined by Section 2.2.2 of [Part4].
			A client that has received multiple partial responses to GET requests
			on a target resource MAY combine those responses into a larger
			continuous range if they share the same strong validator.
			If the most recent response is an incomplete 200 (OK) response, then
			the header fields of that response are used for any combined response
			and replace those of the matching stored responses.
			If the most recent response is a 206 (Partial Content) response and
			at least one of the matching stored responses is a 200 (OK), then the
			combined response header fields consist of the most recent 200
			response's header fields. If all of the matching stored responses
			are 206 responses, then the stored response with the most recent
			header fields is used as the source of header fields for the combined
			response, except that the client MUST use other header fields
			provided in the new response, aside from Content-Range, to replace
			all instances of the corresponding header fields in the stored
			response.
			The combined response message body consists of the union of partial
			content ranges in the new response and each of the selected
			responses. If the union consists of the entire range of the
			representation, then the client MUST record the combined response as
			if it were a complete 200 (OK) response, including a Content-Length
			header field that reflects the complete length. Otherwise, the
			client MUST record the set of continuous ranges as one of the
			following: an incomplete 200 (OK) response if the combined response
			is a prefix of the representation, a single 206 (Partial Content)
			response containing a multipart/byteranges body, or multiple 206
			(Partial Content) responses, each with one continuous range that is
			indicated by a Content-Range header field.
			4.4. 416 Range Not Satisfiable
			The 416 (Range Not Satisfiable) status code indicates that none of
			the ranges in the request's Range header field (Section 3.1) overlap
			the current extent of the selected resource or that the set of ranges
			requested has been rejected due to invalid ranges or an excessive
			request of small or overlapping ranges.
			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
			the current length of the selected representation. When this status
			code is generated in response to a byte range request, the sender
			SHOULD generate a Content-Range header field specifying the current
			length of the selected representation (Section 4.2).
			For example:
			HTTP/1.1 416 Range Not Satisfiable
			Date: Mon, 20 Jan 2012 15:41:54 GMT
			Content-Range: bytes */47022
			Note: Because servers are free to ignore Range, many
			implementations will simply respond with 200 (OK) if the requested
			ranges are invalid or not satisfiable. That is partly because
			most clients are prepared to receive a 200 (OK) to complete the
			task (albeit less efficiently) and partly because clients might
			not stop making an invalid partial request until they have
			received a complete representation. Thus, clients cannot depend
			on receiving a 416 (Range Not Satisfiable) response even when it
			is most appropriate.
			5. IANA Considerations
			5.1. Range Unit Registry
			The HTTP Range Unit Registry defines the name space for the range
			unit names and refers to their corresponding specifications. The
			registry is maintained at
			<http://www.iana.org/assignments/http-parameters>.
			5.1.1. Procedure
			Registration of an HTTP Range Unit MUST include the following fields:
			o Name
			o Description
			o Pointer to specification text
			Values to be added to this name space require IETF Review (see
			[RFC5226], Section 4.1).
			5.1.2. Registrations
			The initial HTTP Range Unit Registry shall contain the registrations
			below:
			+-------------+---------------------------------------+-------------+
			| Range Unit | Description | Reference |
			| Name | | |
			+-------------+---------------------------------------+-------------+
			| bytes | a range of octets | Section 2.1 |
			| none | reserved as keyword, indicating no | Section 2.3 |
			| | ranges are supported | |
			+-------------+---------------------------------------+-------------+
			The change controller is: "IETF (iesg@ietf.org) - Internet
			Engineering Task Force".
			5.2. Status Code Registration
	The HTTP Status Code Registry located at		The HTTP Status Code Registry located at
	<http://www.iana.org/assignments/http-status-codes> shall be updated		<http://www.iana.org/assignments/http-status-codes> shall be updated
	with the registrations below:		with the registrations below:
	+-------+---------------------------------+-------------+		+-------+-----------------------+-------------+
	| Value | Description | Reference |		| Value | Description | Reference |
	+-------+---------------------------------+-------------+		+-------+-----------------------+-------------+
	| 206 | Partial Content | Section 3.1 |		| 206 | Partial Content | Section 4.1 |
	| 416 | Requested Range Not Satisfiable | Section 3.2 |		| 416 | Range Not Satisfiable | Section 4.4 |
	+-------+---------------------------------+-------------+		+-------+-----------------------+-------------+
	6.2. Header Field Registration		5.3. Header Field Registration
	The Message Header Field Registry located at <http://www.iana.org/		The Message Header Field Registry located at <http://www.iana.org/
	assignments/message-headers/message-header-index.html> shall be		assignments/message-headers/message-header-index.html> shall be
	updated with the permanent registrations below (see [RFC3864]):		updated with the permanent registrations below (see [BCP90]):
	+-------------------+----------+----------+-------------+		+-------------------+----------+----------+-------------+
	| Header Field Name | Protocol | Status | Reference |		| Header Field Name | Protocol | Status | Reference |
	+-------------------+----------+----------+-------------+		+-------------------+----------+----------+-------------+
	| Accept-Ranges | http | standard | Section 5.1 |		| Accept-Ranges | http | standard | Section 2.3 |
	| Content-Range | http | standard | Section 5.2 |		| Content-Range | http | standard | Section 4.2 |
	| If-Range | http | standard | Section 5.3 |		| If-Range | http | standard | Section 3.2 |
	| Range | http | standard | Section 5.4 |		| Range | http | standard | Section 3.1 |
	+-------------------+----------+----------+-------------+		+-------------------+----------+----------+-------------+
	The change controller is: "IETF (iesg@ietf.org) - Internet		The change controller is: "IETF (iesg@ietf.org) - Internet
	Engineering Task Force".		Engineering Task Force".
	6.3. Range Specifier Registration		6. Security Considerations
	The registration procedure for HTTP Range Specifiers is defined by
	Section 2.1 of this document.
	The HTTP Range Specifier Registry shall be created at
	<http://www.iana.org/assignments/http-range-specifiers> and be
	populated with the registrations below:
	+---------------+-------------------------------------+-------------+
	| Range | Description | Reference |
	| Specifier | | |
	| Name | | |
	+---------------+-------------------------------------+-------------+
	| bytes | a range of octets | Section 2 |
	| none | reserved as keyword, indicating no | Section 5.1 |
	| | ranges are supported | |
	+---------------+-------------------------------------+-------------+
	The change controller is: "IETF (iesg@ietf.org) - Internet
	Engineering Task Force".
	7. Security Considerations
	This section is meant to inform application developers, information		This section is meant to inform developers, information providers,
	providers, and users of the security limitations in HTTP/1.1 as		and users of known security concerns specific to the HTTP/1.1 range
	described by this document. The discussion does not include		request mechanisms. More general security considerations are
	definitive solutions to the problems revealed, though it does make		addressed in HTTP messaging [Part1] and semantics [Part2].
	some suggestions for reducing security risks.
	7.1. Overlapping Ranges		6.1. Denial of Service Attacks using Range
	Range requests containing overlapping ranges can lead to the		Unconstrained multiple range requests are susceptible to denial of
	situation where a server is sending far more data than the size of		service attacks because the effort required to request many
	the complete resource representation.		overlapping ranges of the same data is tiny compared to the time,
			memory, and bandwidth consumed by attempting to serve the requested
			data in many parts. Servers ought to ignore, coalesce, or reject
			egregious range requests, such as requests for more than two
			overlapping ranges or for many small ranges in a single set,
			particularly when the ranges are requested out of order for no
			apparent reason. Multipart range requests are not designed to
			support random access.
	8. Acknowledgments		7. Acknowledgments
	See Section 9 of [Part1].		See Section 9 of [Part1].
	9. References		8. References
	9.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-21 (work in progress),		draft-ietf-httpbis-p1-messaging-22 (work in progress),
	October 2012.		February 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-21 (work in progress),		draft-ietf-httpbis-p2-semantics-22 (work in progress),
	October 2012.		February 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-21 (work in progress),		draft-ietf-httpbis-p4-conditional-22 (work in progress),
	October 2012.		February 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-21 (work in progress),		draft-ietf-httpbis-p6-cache-22 (work in progress),
	October 2012.		February 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.
	9.2. Informative References		8.2. Informative References
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext		Specifications and Registration Procedures", BCP 13,
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.		RFC 6838, January 2013.
	[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration		[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
	Procedures for Message Header Fields", BCP 90, RFC 3864,		Procedures for Message Header Fields", BCP 90, RFC 3864,
	September 2004.		September 2004.
	[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Registration Procedures", BCP 13, RFC 4288, December 2005.		Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
			Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.		May 2008.
	Appendix A. Internet Media Type multipart/byteranges		Appendix A. Internet Media Type multipart/byteranges
	When an HTTP 206 (Partial Content) response message includes the		When a 206 (Partial Content) response message includes the content of
	content of multiple ranges (a response to a request for multiple non-		multiple ranges, they are transmitted as body parts in a multipart
	overlapping ranges), these are transmitted as a multipart message		message body ([RFC2046], Section 5.1) with the media type of
	body ([RFC2046], Section 5.1). The media type for this purpose is		"multipart/byteranges". The following definition is to be registered
	called "multipart/byteranges". The following is to be registered		with IANA [BCP13].
	with IANA [RFC4288].
	The multipart/byteranges media type includes one or more parts, each		The multipart/byteranges media type includes one or more body parts,
	with its own Content-Type and Content-Range fields. The required		each with its own Content-Type and Content-Range fields. The
	boundary parameter specifies the boundary string used to separate		required boundary parameter specifies the boundary string used to
	each body-part.		separate each body part.
	Type name: multipart		Type name: multipart
	Subtype name: byteranges		Subtype name: byteranges
	Required parameters: boundary		Required parameters: boundary
	Optional parameters: none		Optional parameters: none
	Encoding considerations: only "7bit", "8bit", or "binary" are		Encoding considerations: only "7bit", "8bit", or "binary" are
	skipping to change at page 18, line 22		skipping to change at page 19, line 47
	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/Change controller: IESG
	Note: Despite the name "multipart/byteranges" is not limited to		Implementation Notes:
	the byte ranges only.
	For example:
	HTTP/1.1 206 Partial Content
	Date: Wed, 15 Nov 1995 06:25:24 GMT
	Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
	Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
	--THIS_STRING_SEPARATES		1. Additional CRLFs might precede the first boundary string in the
	Content-type: application/pdf		body.
	Content-range: bytes 500-999/8000
	...the first range...		2. Although [RFC2046] permits the boundary string to be quoted, some
	--THIS_STRING_SEPARATES		existing implementations handle a quoted boundary string
	Content-type: application/pdf		incorrectly.
	Content-range: bytes 7000-7999/8000
	...the second range		3. A number of clients and servers were coded to an early draft of
	--THIS_STRING_SEPARATES--		the byteranges specification that used a media type of multipart/
			x-byteranges, which is almost (but not quite) compatible with
			this type.
	Another example, using the "exampleunit" range unit:		Despite the name, the "multipart/byteranges" media type is not
			limited to byte ranges. The following example uses an "exampleunit"
			range unit:
	HTTP/1.1 206 Partial Content		HTTP/1.1 206 Partial Content
	Date: Tue, 14 Nov 1995 06:25:24 GMT		Date: Tue, 14 Nov 1995 06:25:24 GMT
	Last-Modified: Tue, 14 July 04:58:08 GMT		Last-Modified: Tue, 14 July 04:58:08 GMT
	Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES		Content-Length: 2331785
			Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
	--THIS_STRING_SEPARATES		--THIS_STRING_SEPARATES
	Content-type: video/example		Content-Type: video/example
	Content-range: exampleunit 1.2-4.3/25		Content-Range: exampleunit 1.2-4.3/25
	...the first range...		...the first range...
	--THIS_STRING_SEPARATES		--THIS_STRING_SEPARATES
	Content-type: video/example		Content-Type: video/example
	Content-range: exampleunit 11.2-14.3/25		Content-Range: exampleunit 11.2-14.3/25
	...the second range		...the second range
	--THIS_STRING_SEPARATES--		--THIS_STRING_SEPARATES--
	Notes:		Appendix B. Changes from RFC 2616
	1. Additional CRLFs MAY precede the first boundary string in the
	body.
	2. Although [RFC2046] permits the boundary string to be quoted, some
	existing implementations handle a quoted boundary string
	incorrectly.
	3. A number of clients and servers were coded to an early draft of		A weak validator cannot be used in a 206 response. (Section 4.1)
	the byteranges specification to use a media type of multipart/
	x-byteranges, which is almost, but not quite compatible with the
	version documented in HTTP/1.1.
	Appendix B. Changes from RFC 2616		The Content-Range header field only has meaning when the status code
			explicitly defines its use. (Section 4.2)
	Introduce Range Specifier Registry. (Section 2.1)		Servers are given more leeway in how they respond to a range request,
			in order to mitigate abuse by malicious (or just greedy) clients.
	Clarify that it is not ok to use a weak validator in a 206 response.		multipart/byteranges can consist of a single part. (Appendix A)
	(Section 3.1)
	Clarify that multipart/byteranges can consist of a single part.		This specification introduces a Range Unit Registry. (Section 5.1)
	(Appendix A)
	Appendix C. Imported ABNF		Appendix C. Imported ABNF
	The following core rules are included by reference, as defined in		The following core rules are included by reference, as defined in
	Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),		Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),
	CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double		CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double
	quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any		quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any
	8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII		8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII
	character).		character).
	Note that all rules derived from token are to be compared case-		Note that all rules derived from token are to be compared case-
	insensitively, like range-unit and acceptable-ranges.		insensitively, like range-unit and acceptable-ranges.
	The rules below are defined in [Part1]:		The rules below are defined in [Part1]:
	OWS = <OWS, defined in [Part1], Section 3.2.1>		OWS = <OWS, defined in [Part1], Section 3.2.3>
	token = <token, defined in [Part1], Section 3.2.4>		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 8.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
	Accept-Ranges = acceptable-ranges		Accept-Ranges = acceptable-ranges
	Content-Range = byte-content-range-spec / other-content-range-spec		Content-Range = byte-content-range / other-content-range
	HTTP-date = <HTTP-date, defined in [Part2], Section 8.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.1>		OWS = <OWS, defined in [Part1], Section 3.2.3>
	Range = byte-ranges-specifier / other-ranges-specifier		Range = byte-ranges-specifier / other-ranges-specifier
	acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS		acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS
	range-unit ] ) ) / "none"		range-unit ] ) ) / "none"
	byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" (		byte-content-range = bytes-unit SP ( byte-range-resp /
	instance-length / "*" )		unsatisfied-range )
	byte-range-resp-spec = ( first-byte-pos "-" last-byte-pos ) / "*"		byte-range = first-byte-pos "-" last-byte-pos
			byte-range-resp = byte-range "/" ( complete-length / "*" )
	byte-range-set = *( "," OWS ) ( byte-range-spec /		byte-range-set = *( "," OWS ) ( byte-range-spec /
	suffix-byte-range-spec ) *( OWS "," [ OWS ( byte-range-spec /		suffix-byte-range-spec ) *( OWS "," [ OWS ( byte-range-spec /
	suffix-byte-range-spec ) ] )		suffix-byte-range-spec ) ] )
	byte-range-spec = first-byte-pos "-" [ last-byte-pos ]		byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
	byte-ranges-specifier = bytes-unit "=" byte-range-set		byte-ranges-specifier = bytes-unit "=" byte-range-set
	bytes-unit = "bytes"		bytes-unit = "bytes"
			complete-length = 1*DIGIT
	entity-tag = <entity-tag, defined in [Part4], Section 2.3>		entity-tag = <entity-tag, defined in [Part4], Section 2.3>
	first-byte-pos = 1*DIGIT		first-byte-pos = 1*DIGIT
	instance-length = 1*DIGIT
	last-byte-pos = 1*DIGIT		last-byte-pos = 1*DIGIT
	other-content-range-spec = other-range-unit SP other-range-resp-spec		other-content-range = other-range-unit SP other-range-resp
	other-range-resp-spec = *CHAR		other-range-resp = *CHAR
	other-range-set = 1*CHAR		other-range-set = 1*CHAR
	other-range-unit = token		other-range-unit = token
	other-ranges-specifier = other-range-unit "=" other-range-set		other-ranges-specifier = other-range-unit "=" other-range-set
	range-unit = bytes-unit / other-range-unit		range-unit = bytes-unit / other-range-unit
	suffix-byte-range-spec = "-" suffix-length		suffix-byte-range-spec = "-" suffix-length
	suffix-length = 1*DIGIT		suffix-length = 1*DIGIT
	token = <token, defined in [Part1], Section 3.2.4>		token = <token, defined in [Part1], Section 3.2.6>
			unsatisfied-range = "*/" complete-length
	Appendix E. Change Log (to be removed by RFC Editor before publication)		Appendix E. Change Log (to be removed by RFC Editor before publication)
	Changes up to the first Working Group Last Call draft are summarized		Changes up to the first Working Group Last Call draft are summarized
	in <http://tools.ietf.org/html/		in <http://tools.ietf.org/html/
	draft-ietf-httpbis-p5-range-19#appendix-D>.		draft-ietf-httpbis-p5-range-19#appendix-D>.
	E.1. Since draft-ietf-httpbis-p5-range-19		E.1. Since draft-ietf-httpbis-p5-range-19
	Closed issues:		Closed issues:
	skipping to change at page 22, line 35		skipping to change at page 23, line 35
	introduction of new IANA registries as normative changes"		introduction of new IANA registries as normative changes"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/369>: "range units		o <http://tools.ietf.org/wg/httpbis/trac/ticket/369>: "range units
	vs leading zeroes vs size"		vs leading zeroes vs size"
	E.2. Since draft-ietf-httpbis-p5-range-20		E.2. Since draft-ietf-httpbis-p5-range-20
	o Conformance criteria and considerations regarding error handling		o Conformance criteria and considerations regarding error handling
	are now defined in Part 1.		are now defined in Part 1.
			E.3. Since draft-ietf-httpbis-p5-range-21
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/175>: "Security
			consideration: range flooding"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/223>: "Allowing
			heuristic caching for new status codes"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/311>: "Add
			limitations to Range to reduce its use as a denial-of-service
			tool"
	Index		Index
	2		2
	206 Partial Content (status code) 5		206 Partial Content (status code) 10
	4		4
	416 Requested Range Not Satisfiable (status code) 6		416 Range Not Satisfiable (status code) 15
	A		A
	Accept-Ranges header field 8		Accept-Ranges header field 7
	C		C
	Content-Range header field 9		Content-Range header field 12
	G		G
	Grammar		Grammar
	Accept-Ranges 8		Accept-Ranges 7
	acceptable-ranges 8		acceptable-ranges 7
	byte-content-range-spec 9		byte-content-range 12
	byte-range-resp-spec 9		byte-range 12
	byte-range-set 12		byte-range-resp 12
	byte-range-spec 12		byte-range-set 5
	byte-ranges-specifier 12		byte-range-spec 5
			byte-ranges-specifier 5
	bytes-unit 5		bytes-unit 5
	Content-Range 9		complete-length 12
	first-byte-pos 12		Content-Range 12
	If-Range 11		first-byte-pos 5
	instance-length 9		If-Range 9
	last-byte-pos 12		last-byte-pos 5
	other-range-unit 5		other-content-range 12
	Range 13		other-range-resp 12
			other-range-unit 5, 7
			Range 7
	range-unit 5		range-unit 5
	ranges-specifier 12		ranges-specifier 5
	suffix-byte-range-spec 12		suffix-byte-range-spec 6
	suffix-length 12		suffix-length 6
			unsatisfied-range 12
	I		I
	If-Range header field 10		If-Range header field 9
	M		M
	Media Type		Media Type
	multipart/byteranges 17		multipart/byteranges 18
	multipart/x-byteranges 19		multipart/x-byteranges 20
	multipart/byteranges Media Type 17		multipart/byteranges Media Type 18
	multipart/x-byteranges Media Type 19		multipart/x-byteranges Media Type 20
	R		R
	Range header field 11		Range header field 7
	Authors' Addresses		Authors' Addresses
	Roy T. Fielding (editor)		Roy T. Fielding (editor)
	Adobe Systems Incorporated		Adobe Systems Incorporated
	345 Park Ave		345 Park Ave
	San Jose, CA 95110		San Jose, CA 95110
	USA		USA
	EMail: fielding@gbiv.com		EMail: fielding@gbiv.com
End of changes. 156 change blocks.
	549 lines changed or deleted		610 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/