draft-ietf-httpbis-p5-range-22.txt		draft-ietf-httpbis-p5-range-23.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: January 16, 2014 J. Reschke, Ed.
	greenbytes		greenbytes
	February 23, 2013		July 15, 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-23
	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 January 16, 2014.
	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 17		skipping to change at page 3, line 17
	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. Byte Ranges . . . . . . . . . . . . . . . . . . . . . . . 5		2.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . . . 5
	2.2. Other Range Units . . . . . . . . . . . . . . . . . . . . 7		2.2. Other Range Units . . . . . . . . . . . . . . . . . . . . 7
	2.3. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7		2.3. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7
	3. Range Requests . . . . . . . . . . . . . . . . . . . . . . . . 7		3. Range Requests . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.1. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 7		3.1. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.2. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 9		3.2. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 9
	4. Responses to a Range Request . . . . . . . . . . . . . . . . . 9		4. Responses to a Range Request . . . . . . . . . . . . . . . . . 10
	4.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 10		4.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 10
	4.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 12		4.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 12
	4.3. Combining Ranges . . . . . . . . . . . . . . . . . . . . . 14		4.3. Combining Ranges . . . . . . . . . . . . . . . . . . . . . 14
	4.4. 416 Range Not Satisfiable . . . . . . . . . . . . . . . . 15		4.4. 416 Range Not Satisfiable . . . . . . . . . . . . . . . . 15
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	5.1. Range Unit Registry . . . . . . . . . . . . . . . . . . . 15		5.1. Range Unit Registry . . . . . . . . . . . . . . . . . . . 15
	5.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 15		5.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 15
	5.1.2. Registrations . . . . . . . . . . . . . . . . . . . . 16		5.1.2. Registrations . . . . . . . . . . . . . . . . . . . . 16
	5.2. Status Code Registration . . . . . . . . . . . . . . . . . 16		5.2. Status Code Registration . . . . . . . . . . . . . . . . . 16
	5.3. Header Field Registration . . . . . . . . . . . . . . . . 16		5.3. Header Field Registration . . . . . . . . . . . . . . . . 16
	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 5, line 22		skipping to change at page 5, line 21
	2.1. Byte Ranges		2.1. Byte Ranges
	Since representation data is transferred in payloads as a sequence of		Since representation data is transferred in payloads as a sequence of
	octets, a byte range is a meaningful substructure for any		octets, a byte range is a meaningful substructure for any
	representation transferable over HTTP (Section 3 of [Part2]). We		representation transferable over HTTP (Section 3 of [Part2]). We
	define the "bytes" range unit for expressing subranges of the data's		define the "bytes" range unit for expressing subranges of the data's
	octet sequence.		octet sequence.
	bytes-unit = "bytes"		bytes-unit = "bytes"
	A byte range operation MAY specify a single range of bytes, or a set		A byte range request can specify a single range of bytes, or a set of
	of ranges within a single representation.		ranges within a single representation.
	byte-ranges-specifier = bytes-unit "=" byte-range-set		byte-ranges-specifier = bytes-unit "=" byte-range-set
	byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec )		byte-range-set = 1#( 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 ]
	first-byte-pos = 1*DIGIT		first-byte-pos = 1*DIGIT
	last-byte-pos = 1*DIGIT		last-byte-pos = 1*DIGIT
	The first-byte-pos value in a byte-range-spec gives the byte-offset		The first-byte-pos value in a byte-range-spec gives the byte-offset
	of the first byte in a range. The last-byte-pos value gives the		of the first byte in a range. The last-byte-pos value gives the
	byte-offset of the last byte in the range; that is, the byte		byte-offset of the last byte in the range; that is, the byte
	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 8, line 28		skipping to change at page 8, line 28
	A client that is requesting multiple ranges SHOULD list those ranges		A client that is requesting multiple ranges SHOULD list those ranges
	in ascending order (the order in which they would typically be		in ascending order (the order in which they would typically be
	received in a complete representation) unless there is a specific		received in a complete representation) unless there is a specific
	need to request a later part earlier. For example, a user agent		need to request a later part earlier. For example, a user agent
	processing a large representation with an internal catalog of parts		processing a large representation with an internal catalog of parts
	might need to request later parts first, particularly if the		might need to request later parts first, particularly if the
	representation consists of pages stored in reverse order and the user		representation consists of pages stored in reverse order and the user
	agent wishes to transfer one page at a time.		agent wishes to transfer one page at a time.
	The Range header field is evaluated after evaluating the		The Range header field is evaluated after evaluating the precondition
	preconditions of [Part4] and only if the result of their evaluation		header fields defined in [Part4], and only if the result in absence
	is leading toward a 200 (OK) response. In other words, Range is		of the Range header field would be a 200 (OK) response. In other
	ignored when a conditional GET would result in a 304 (Not Modified)		words, Range is ignored when a conditional GET would result in a 304
	response.		(Not Modified) response.
	The If-Range header field (Section 3.2) can be used as a precondition		The If-Range header field (Section 3.2) can be used as a precondition
	to applying the Range header field.		to applying the Range header field.
	If all of the preconditions are true, the server supports the Range		If all of the preconditions are true, the server supports the Range
	header field for the target resource, and the specified range(s) are		header field for the target resource, and the specified range(s) are
	valid and satisfiable (as defined in Section 2.1), the server SHOULD		valid and satisfiable (as defined in Section 2.1), the server SHOULD
	send a 206 (Partial Content) response with a payload containing one		send a 206 (Partial Content) response with a payload containing one
	or more partial representations that correspond to the satisfiable		or more partial representations that correspond to the satisfiable
	ranges requested, as defined in Section 4.		ranges requested, as defined in Section 4.
	skipping to change at page 9, line 22		skipping to change at page 9, line 22
	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 requesting in Range;		unchanged, send me the part(s) that I am requesting in Range;
	otherwise, send me the entire 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		A client MUST NOT generate an If-Range header field containing an
	field value and MUST NOT use a Last-Modified date in an If-Range		entity-tag that is marked as weak. A client MUST NOT generate an If-
	field value unless it has no entity-tag for the representation and		Range header field containing a Last-Modified date unless the client
	the Last-Modified date it does have for the representation is strong		has no entity-tag for the corresponding representation and the Last-
	in the sense defined by Section 2.2.2 of [Part4].		Modified date is strong 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.)
	A client MUST NOT generate an If-Range header field in a request that		A client MUST NOT generate an If-Range header field in a request that
	skipping to change at page 10, line 4		skipping to change at page 10, line 6
	field received in a request for a target resource that does not		field received in a request for a target resource that does not
	support Range requests.		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 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 11, line 40		skipping to change at page 11, line 40
	parameter length, it can be less efficient to transfer many small		parameter length, it can be less efficient to transfer many small
	disjoint parts than it is to transfer the entire selected		disjoint parts than it is to transfer the entire selected
	representation.		representation.
	A server MUST NOT generate a multipart response to a request for a		A server MUST NOT generate a multipart response to a request for a
	single range, since a client that does not request multiple parts		single range, since a client that does not request multiple parts
	might not support multipart responses. However, a server MAY		might not support multipart responses. However, a server MAY
	generate a multipart/byteranges payload with only a single body part		generate a multipart/byteranges payload with only a single body part
	if multiple ranges were requested and only one range was found to be		if multiple ranges were requested and only one range was found to be
	satisfiable or only one range remained after coalescing. A client		satisfiable or only one range remained after coalescing. A client
	that cannot process a multipart/byteranges response MUST NOT ask for		that cannot process a multipart/byteranges response MUST NOT generate
	multiple ranges in a single request.		a request that asks for multiple ranges.
	When a multipart response payload is generated, the server SHOULD		When a multipart response payload is generated, the server SHOULD
	send the parts in the same order that the corresponding byte-range-		send the parts in the same order that the corresponding byte-range-
	spec appeared in the received Range header field, excluding those		spec appeared in the received Range header field, excluding those
	ranges that were deemed unsatisfiable or that were coalesced into		ranges that were deemed unsatisfiable or that were coalesced into
	other ranges. A client that receives a multipart response MUST		other ranges. A client that receives a multipart response MUST
	inspect the Content-Range header field present in each body part in		inspect the Content-Range header field present in each body part in
	order to determine which range is contained in that body part; a		order to determine which range is contained in that body part; a
	client cannot rely on receiving the same ranges that it requested,		client cannot rely on receiving the same ranges that it requested,
	nor the same order that it requested.		nor the same order that it requested.
	skipping to change at page 14, line 47		skipping to change at page 14, line 47
	are 206 responses, then the stored response with the most recent		are 206 responses, then the stored response with the most recent
	header fields is used as the source of header fields for the combined		header fields is used as the source of header fields for the combined
	response, except that the client MUST use other header fields		response, except that the client MUST use other header fields
	provided in the new response, aside from Content-Range, to replace		provided in the new response, aside from Content-Range, to replace
	all instances of the corresponding header fields in the stored		all instances of the corresponding header fields in the stored
	response.		response.
	The combined response message body consists of the union of partial		The combined response message body consists of the union of partial
	content ranges in the new response and each of the selected		content ranges in the new response and each of the selected
	responses. If the union consists of the entire range of the		responses. If the union consists of the entire range of the
	representation, then the client MUST record the combined response as		representation, then the client MUST process the combined response as
	if it were a complete 200 (OK) response, including a Content-Length		if it were a complete 200 (OK) response, including a Content-Length
	header field that reflects the complete length. Otherwise, the		header field that reflects the complete length. Otherwise, the
	client MUST record the set of continuous ranges as one of the		client MUST process the set of continuous ranges as one of the
	following: an incomplete 200 (OK) response if the combined response		following: an incomplete 200 (OK) response if the combined response
	is a prefix of the representation, a single 206 (Partial Content)		is a prefix of the representation, a single 206 (Partial Content)
	response containing a multipart/byteranges body, or multiple 206		response containing a multipart/byteranges body, or multiple 206
	(Partial Content) responses, each with one continuous range that is		(Partial Content) responses, each with one continuous range that is
	indicated by a Content-Range header field.		indicated by a Content-Range header field.
	4.4. 416 Range Not Satisfiable		4.4. 416 Range Not Satisfiable
	The 416 (Range Not Satisfiable) status code indicates that none of		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 ranges in the request's Range header field (Section 3.1) overlap
	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. That is partly because
	most clients are prepared to receive a 200 (OK) to complete the		most clients are prepared to receive a 200 (OK) to complete the
	task (albeit less efficiently) and partly because clients might		task (albeit less efficiently) and partly because clients might
	not stop making an invalid partial request until they have		not stop making an invalid partial request until they have
	received a complete representation. Thus, clients cannot depend		received a complete representation. Thus, clients cannot depend
	on receiving a 416 (Range Not Satisfiable) response even when it		on receiving a 416 (Range Not Satisfiable) response even when it
	is most appropriate.		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-23 (work in progress),
	February 2013.		July 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-23 (work in progress),
	February 2013.		July 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-23 (work in progress),
	February 2013.		July 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-23 (work in progress),
	February 2013.		July 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"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/462>: "Editorial
			suggestions"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/485>: "MUSTs and
			other feedback"
	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. 28 change blocks.
	44 lines changed or deleted		79 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/