draft-ietf-httpbis-p5-range-11.txt		draft-ietf-httpbis-p5-range-12.txt
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis Working Group R. Fielding, Ed.
	Internet-Draft Day Software		Internet-Draft Day Software
	Obsoletes: 2616 (if approved) J. Gettys		Obsoletes: 2616 (if approved) J. Gettys
	Intended status: Standards Track Alcatel-Lucent		Intended status: Standards Track Alcatel-Lucent
	Expires: February 5, 2011 J. Mogul		Expires: April 28, 2011 J. Mogul
	HP		HP
	H. Frystyk		H. Frystyk
	Microsoft		Microsoft
	L. Masinter		L. Masinter
	Adobe Systems		Adobe Systems
	P. Leach		P. Leach
	Microsoft		Microsoft
	T. Berners-Lee		T. Berners-Lee
	W3C/MIT		W3C/MIT
	Y. Lafon, Ed.		Y. Lafon, Ed.
	W3C		W3C
	J. Reschke, Ed.		J. Reschke, Ed.
	greenbytes		greenbytes
	August 4, 2010		October 25, 2010
	HTTP/1.1, part 5: Range Requests and Partial Responses		HTTP/1.1, part 5: Range Requests and Partial Responses
	draft-ietf-httpbis-p5-range-11		draft-ietf-httpbis-p5-range-12
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	protocol for distributed, collaborative, hypermedia information		protocol for distributed, collaborative, hypermedia information
	systems. HTTP has been in use by the World Wide Web global		systems. HTTP has been in use by the World Wide Web global
	information initiative since 1990. This document is Part 5 of the		information initiative since 1990. This document is Part 5 of the
	seven-part specification that defines the protocol referred to as		seven-part specification that defines the protocol referred to as
	"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines		"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines
	range-specific requests and the rules for constructing and combining		range-specific requests and the rules for constructing and combining
	responses to those requests.		responses to those requests.
	Editorial Note (To be removed by RFC Editor)		Editorial Note (To be removed by RFC Editor)
	Discussion of this draft should take place on the HTTPBIS working		Discussion of this draft should take place on the HTTPBIS working
	group mailing list (ietf-http-wg@w3.org). The current issues list is		group mailing list (ietf-http-wg@w3.org). The current issues list is
	at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related		at <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 D.12.		The changes in this draft are summarized in Appendix D.13.
	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 February 5, 2011.		This Internet-Draft will expire on April 28, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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 7		skipping to change at page 2, line 47
	modifications of such material outside the IETF Standards Process.		modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling		Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5		1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5		1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
	1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6		1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5
	1.2.2. ABNF Rules defined in other Parts of the		1.2.2. ABNF Rules defined in other Parts of the
	Specification . . . . . . . . . . . . . . . . . . . . 6		Specification . . . . . . . . . . . . . . . . . . . . 5
	2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 6		2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 5
	3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7		3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 6
	3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 7		3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 6
	3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 8		3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 7
	4. Combining Ranges . . . . . . . . . . . . . . . . . . . . . . . 8		4. Combining Ranges . . . . . . . . . . . . . . . . . . . . . . . 7
	5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 8		5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 7
	5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 9		5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 8
	5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 9		5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 8
	5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 11		5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 10
	5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 12		5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 12		5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 11
	5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 14		5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 13
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	6.1. Status Code Registration . . . . . . . . . . . . . . . . . 15		6.1. Status Code Registration . . . . . . . . . . . . . . . . . 14
	6.2. Header Field Registration . . . . . . . . . . . . . . . . 15		6.2. Header Field Registration . . . . . . . . . . . . . . . . 14
	6.3. Range Specifier Registration . . . . . . . . . . . . . . . 16		6.3. Range Specifier Registration . . . . . . . . . . . . . . . 15
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 16		7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 16		9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
	9.2. Informative References . . . . . . . . . . . . . . . . . . 17		9.2. Informative References . . . . . . . . . . . . . . . . . . 16
	Appendix A. Internet Media Type multipart/byteranges . . . . . . 17		Appendix A. Internet Media Type multipart/byteranges . . . . . . 16
	Appendix B. Compatibility with Previous Versions . . . . . . . . 20		Appendix B. Compatibility with Previous Versions . . . . . . . . 19
	B.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 20		B.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 19
	Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 20		Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 19
	Appendix D. Change Log (to be removed by RFC Editor before		Appendix D. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 21		publication) . . . . . . . . . . . . . . . . . . . . 20
	D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 21		D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 20
	D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 21		D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 20
	D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 22		D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 21
	D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 22		D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 21
	D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 22		D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 21
	D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 22		D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 21
	D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 22		D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 21
	D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 23		D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 22
	D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 23		D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 22
	D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 23		D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 22
	D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 23		D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 22
	D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 23		D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 22
			D.13. Since draft-ietf-httpbis-p5-range-11 . . . . . . . . . . . 23
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	HTTP clients often encounter interrupted data transfers as a result		HTTP clients often encounter interrupted data transfers as a result
	of cancelled requests or dropped connections. When a cache has		of cancelled requests or dropped connections. When a cache has
	stored a partial representation, it is desirable to request the		stored a partial representation, it is desirable to request the
	remainder of that representation in a subsequent request rather than		remainder of that representation in a subsequent request rather than
	transfer the entire representation. There are also a number of Web		transfer the entire representation. There are also a number of Web
	applications that benefit from being able to request only a subset of		applications that benefit from being able to request only a subset of
	a larger representation, such as a single page of a very large		a larger representation, such as a single page of a very large
	skipping to change at page 6, line 44		skipping to change at page 5, line 44
	range-unit = bytes-unit / other-range-unit		range-unit = bytes-unit / other-range-unit
	bytes-unit = "bytes"		bytes-unit = "bytes"
	other-range-unit = token		other-range-unit = token
	HTTP/1.1 has been designed to allow implementations of applications		HTTP/1.1 has been designed to allow implementations of applications
	that do not depend on knowledge of ranges. The only range unit		that do not depend on knowledge of ranges. The only range unit
	defined by HTTP/1.1 is "bytes". Additional specifiers can be defined		defined by HTTP/1.1 is "bytes". Additional specifiers can be defined
	as described in Section 2.1.		as described in Section 2.1.
	If a range unit is not understood in a request, a server MUST ignore		If a range unit is not understood in a request, a server MUST ignore
	the whole Range header (Section 5.4). If a range unit is not		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		understood in a response, an intermediary SHOULD pass the response to
	the client; a client MUST fail.		the client; a client MUST fail.
	2.1. Range Specifier Registry		2.1. Range Specifier Registry
	The HTTP Ranger Specifier Registry defines the name space for the		The HTTP Ranger Specifier Registry defines the name space for the
	range specifier names.		range specifier names.
	Registrations MUST include the following fields:		Registrations MUST include the following fields:
	skipping to change at page 7, line 50		skipping to change at page 6, line 50
	and/or Vary, if the header field would have been sent in a 200		and/or Vary, if the header field would have been sent in a 200
	response to the same request		response to the same request
	If the 206 response is the result of an If-Range request, the		If the 206 response is the result of an If-Range request, the
	response SHOULD NOT include other representation header fields.		response SHOULD NOT include other representation header fields.
	Otherwise, the response MUST include all of the representation header		Otherwise, the response MUST include all of the representation header
	fields that would have been returned with a 200 (OK) response to the		fields that would have been returned with a 200 (OK) response to the
	same request.		same request.
	A cache MUST NOT combine a 206 response with other previously cached		A cache MUST NOT combine a 206 response with other previously cached
	content if the ETag or Last-Modified headers do not match exactly,		content if the ETag or Last-Modified header fields do not match
	see Section 4.		exactly, see Section 4.
	A cache that does not support the Range and Content-Range headers		A cache that does not support the Range and Content-Range header
	MUST NOT cache 206 (Partial Content) responses. Furthermore, if a		fields MUST NOT cache 206 (Partial Content) responses. Furthermore,
	response uses a range unit that is not understood by the cache, then		if a response uses a range unit that is not understood by the cache,
	it MUST NOT be cached either.		then it MUST NOT be cached either.
	3.2. 416 Requested Range Not Satisfiable		3.2. 416 Requested Range Not Satisfiable
	A server SHOULD return a response with this status code if a request		A server SHOULD return a response with this status code if a request
	included a Range request-header field (Section 5.4), and none of the		included a Range request-header field (Section 5.4), and none of the
	ranges-specifier values in this field overlap the current extent of		ranges-specifier values in this field overlap the current extent of
	the selected resource, and the request did not include an If-Range		the selected resource, and the request did not include an If-Range
	request-header field (Section 5.3). (For byte-ranges, this means		request-header field (Section 5.3). (For byte-ranges, this means
	that the first-byte-pos of all of the byte-range-spec values were		that the first-byte-pos of all of the byte-range-spec values were
	greater than the current length of the selected resource.)		greater than the current length of the selected resource.)
	skipping to change at page 9, line 19		skipping to change at page 8, line 19
	Accept-Ranges = "Accept-Ranges" ":" OWS Accept-Ranges-v		Accept-Ranges = "Accept-Ranges" ":" OWS Accept-Ranges-v
	Accept-Ranges-v = acceptable-ranges		Accept-Ranges-v = 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 accept 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 for the resource involved. Range		without having received this header field for the resource involved.
	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 accept any kind of range request for a resource
	MAY send		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		5.2. Content-Range
	skipping to change at page 10, line 7		skipping to change at page 9, line 7
	byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)		byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)
	/ "*"		/ "*"
	instance-length = 1*DIGIT		instance-length = 1*DIGIT
	other-content-range-spec = other-range-unit SP		other-content-range-spec = other-range-unit SP
	other-range-resp-spec		other-range-resp-spec
	other-range-resp-spec = *CHAR		other-range-resp-spec = *CHAR
	The header SHOULD indicate the total length of the full		The header field SHOULD indicate the total length of the full
	representation, unless this length is unknown or difficult to		representation, unless this length is unknown or difficult to
	determine. The asterisk "*" character means that the instance-length		determine. The asterisk "*" character means that the instance-length
	is unknown at the time when the response was generated.		is unknown at the time when the response was generated.
	Unlike byte-ranges-specifier values (see Section 5.4.1), a byte-		Unlike byte-ranges-specifier values (see Section 5.4.1), a byte-
	range-resp-spec MUST only specify one range, and MUST contain		range-resp-spec MUST only specify one range, and MUST contain
	absolute byte positions for both the first and last byte of the		absolute byte positions for both the first and last byte of the
	range.		range.
	A byte-content-range-spec with a byte-range-resp-spec whose last-		A byte-content-range-spec with a byte-range-resp-spec whose last-
	skipping to change at page 10, line 52		skipping to change at page 9, line 52
	bytes 500-1233/1234		bytes 500-1233/1234
	o The last 500 bytes:		o The last 500 bytes:
	bytes 734-1233/1234		bytes 734-1233/1234
	When an HTTP message includes the content of a single range (for		When an HTTP message includes the content of a single range (for
	example, a response to a request for a single range, or to a request		example, a response to a request for a single range, or to a request
	for a set of ranges that overlap without any holes), this content is		for a set of ranges that overlap without any holes), this content is
	transmitted with a Content-Range header, and a Content-Length header		transmitted with a Content-Range header field, and a Content-Length
	showing the number of bytes actually transferred. For example,		header field showing the number of bytes actually transferred. 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
	Content-Range: bytes 21010-47021/47022		Content-Range: bytes 21010-47021/47022
	Content-Length: 26012		Content-Length: 26012
	Content-Type: image/gif		Content-Type: image/gif
	When an HTTP message includes the content of multiple ranges (for		When an HTTP message includes the content of multiple ranges (for
	example, a response to a request for multiple non-overlapping		example, a response to a request for multiple non-overlapping
	skipping to change at page 11, line 43		skipping to change at page 10, line 44
	If the server receives a request (other than one including an If-		If the server receives a request (other than one including an If-
	Range request-header field) with an unsatisfiable Range request-		Range request-header field) with an unsatisfiable Range request-
	header field (that is, all of whose byte-range-spec values have a		header field (that is, all of whose byte-range-spec values have a
	first-byte-pos value greater than the current length of the selected		first-byte-pos value greater than the current length of the selected
	resource), it SHOULD return a response code of 416 (Requested range		resource), it SHOULD return a response code of 416 (Requested range
	not satisfiable) (Section 3.2).		not satisfiable) (Section 3.2).
	Note: Clients cannot depend on servers to send a 416 (Requested		Note: Clients cannot depend on servers to send a 416 (Requested
	range not satisfiable) response instead of a 200 (OK) response for		range not satisfiable) response instead of a 200 (OK) response for
	an unsatisfiable Range request-header, since not all servers		an unsatisfiable Range request-header field, since not all servers
	implement this request-header.		implement this request-header field.
	5.3. If-Range		5.3. If-Range
	If a client has a partial copy of a representation in its cache, and		If a client has a partial copy of a representation in its cache, and
	wishes to have an up-to-date copy of the entire representation in its		wishes to have an up-to-date copy of the entire representation in its
	cache, it could use the Range request-header with a conditional GET		cache, it could use the Range request-header field with a conditional
	(using either or both of If-Unmodified-Since and If-Match.) However,		GET (using either or both of If-Unmodified-Since and If-Match.)
	if the condition fails because the representation has been modified,		However, if the condition fails because the representation has been
	the client would then have to make a second request to obtain the		modified, the client would then have to make a second request to
	entire current representation.		obtain the entire current representation.
	The "If-Range" request-header field allows a client to "short-		The "If-Range" request-header field allows a client to "short-
	circuit" the second request. Informally, its meaning is "if the		circuit" the second request. Informally, its meaning is "if the
	representation is unchanged, send me the part(s) that I am missing;		representation is unchanged, send me the part(s) that I am missing;
	otherwise, send me the entire new representation".		otherwise, send me the entire new representation".
	If-Range = "If-Range" ":" OWS If-Range-v		If-Range = "If-Range" ":" OWS If-Range-v
	If-Range-v = entity-tag / HTTP-date		If-Range-v = entity-tag / HTTP-date
	If the client has no entity-tag for a representation, but does have a		If the client has no entity-tag for a representation, but does have a
	Last-Modified date, it MAY use that date in an If-Range header. (The		Last-Modified date, it MAY use that date in an If-Range header field.
	server can distinguish between a valid HTTP-date and any form of		(The server can distinguish between a valid HTTP-date and any form of
	entity-tag by examining no more than two characters.) The If-Range		entity-tag by examining no more than two characters.) The If-Range
	header SHOULD only be used together with a Range header, and MUST be		header field SHOULD only be used together with a Range header field,
	ignored if the request does not include a Range header, or if the		and MUST be ignored if the request does not include a Range header
	server does not support the sub-range operation.		field, or if the server does not support the sub-range operation.
	If the entity-tag given in the If-Range header matches the current		If the entity-tag given in the If-Range header field matches the
	cache validator for the representation, then the server SHOULD		current cache validator for the representation, then the server
	provide the specified sub-range of the representation using a 206		SHOULD provide the specified sub-range of the representation using a
	(Partial Content) response. If the cache validator does not match,		206 (Partial Content) response. If the cache validator does not
	then the server SHOULD return the entire representation using a 200		match, then the server SHOULD return the entire representation using
	(OK) response.		a 200 (OK) response.
	5.4. Range		5.4. Range
	5.4.1. Byte Ranges		5.4.1. Byte Ranges
	Since all HTTP representations are transferred as sequences of bytes,		Since all HTTP representations are transferred as sequences of bytes,
	the concept of a byte range is meaningful for any HTTP		the concept of a byte range is meaningful for any HTTP
	representation. (However, not all clients and servers need to		representation. (However, not all clients and servers need to
	support byte-range operations.)		support byte-range operations.)
	skipping to change at page 14, line 39		skipping to change at page 13, line 39
	The "Range" request-header field defines the GET method (conditional		The "Range" request-header field defines the GET method (conditional
	or not) to request one or more sub-ranges of the response		or not) to request one or more sub-ranges of the response
	representation body, instead of the entire representation body.		representation body, instead of the entire representation body.
	Range = "Range" ":" OWS Range-v		Range = "Range" ":" OWS Range-v
	Range-v = byte-ranges-specifier		Range-v = byte-ranges-specifier
	/ other-ranges-specifier		/ other-ranges-specifier
	other-ranges-specifier = other-range-unit "=" other-range-set		other-ranges-specifier = other-range-unit "=" other-range-set
	other-range-set = 1*CHAR		other-range-set = 1*CHAR
	A server MAY ignore the Range header. However, HTTP/1.1 origin		A server MAY ignore the Range header field. However, HTTP/1.1 origin
	servers and intermediate caches ought to support byte ranges when		servers and intermediate caches ought to support byte ranges when
	possible, since Range supports efficient recovery from partially		possible, since Range supports efficient recovery from partially
	failed transfers, and supports efficient partial retrieval of large		failed transfers, and supports efficient partial retrieval of large
	representations.		representations.
	If the server supports the Range header and the specified range or		If the server supports the Range header field and the specified range
	ranges are appropriate for the representation:		or ranges are appropriate for the representation:
	o The presence of a Range header in an unconditional GET modifies		o The presence of a Range header field in an unconditional GET
	what is returned if the GET is otherwise successful. In other		modifies what is returned if the GET is otherwise successful. In
	words, the response carries a status code of 206 (Partial Content)		other words, the response carries a status code of 206 (Partial
	instead of 200 (OK).		Content) instead of 200 (OK).
	o The presence of a Range header in a conditional GET (a request		o The presence of a Range header field in a conditional GET (a
	using one or both of If-Modified-Since and If-None-Match, or one		request using one or both of If-Modified-Since and If-None-Match,
	or both of If-Unmodified-Since and If-Match) modifies what is		or one or both of If-Unmodified-Since and If-Match) modifies what
	returned if the GET is otherwise successful and the condition is		is returned if the GET is otherwise successful and the condition
	true. It does not affect the 304 (Not Modified) response returned		is true. It does not affect the 304 (Not Modified) response
	if the conditional is false.		returned if the conditional is false.
	In some cases, it might be more appropriate to use the If-Range		In some cases, it might be more appropriate to use the If-Range
	header (see Section 5.3) in addition to the Range header.		header field (see Section 5.3) in addition to the Range header field.
	If a proxy that supports ranges receives a Range request, forwards		If a proxy that supports ranges receives a Range request, forwards
	the request to an inbound server, and receives an entire		the request to an inbound server, and receives an entire
	representation in reply, it SHOULD only return the requested range to		representation in reply, it MAY only return the requested range to
	its client. It SHOULD store the entire received response in its		its client.
	cache if that is consistent with its cache allocation policies.
	6. IANA Considerations		6. IANA Considerations
	6.1. Status Code Registration		6.1. 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:
	+-------+---------------------------------+-------------+		+-------+---------------------------------+-------------+
	skipping to change at page 16, line 44		skipping to change at page 15, line 44
	Larry Masinter, Jeff Mogul, Lou Montulli, David W. Morris, Luigi		Larry Masinter, Jeff Mogul, Lou Montulli, David W. Morris, Luigi
	Rizzo, and Bill Weihl.		Rizzo, and Bill Weihl.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,		and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
	and Message Parsing", draft-ietf-httpbis-p1-messaging-11		and Message Parsing", draft-ietf-httpbis-p1-messaging-12
	(work in progress), August 2010.		(work in progress), October 2010.
	[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional		and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
	Requests", draft-ietf-httpbis-p4-conditional-11 (work in		Requests", draft-ietf-httpbis-p4-conditional-12 (work in
	progress), August 2010.		progress), October 2010.
	[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 21, line 35		skipping to change at page 20, line 35
	ABNF diagnostics:		ABNF diagnostics:
	; Accept-Ranges defined but not used		; Accept-Ranges defined but not used
	; Content-Range defined but not used		; Content-Range defined but not used
	; If-Range defined but not used		; If-Range defined but not used
	; Range defined but not used		; Range defined but not used
	Appendix D. Change Log (to be removed by RFC Editor before publication)		Appendix D. Change Log (to be removed by RFC Editor before publication)
	D.1. Since RFC2616		D.1. Since RFC 2616
	Extracted relevant partitions from [RFC2616].		Extracted relevant partitions from [RFC2616].
	D.2. Since draft-ietf-httpbis-p5-range-00		D.2. Since draft-ietf-httpbis-p5-range-00
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/18>: "Cache		o <http://tools.ietf.org/wg/httpbis/trac/ticket/18>: "Cache
	validators in 206 responses"		validators in 206 responses"
	(<http://purl.org/NET/http-errata#ifrange206>)		(<http://purl.org/NET/http-errata#ifrange206>)
	skipping to change at page 22, line 20		skipping to change at page 21, line 20
	RFC4288"		RFC4288"
	Ongoing work on ABNF conversion		Ongoing work on ABNF conversion
	(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):		(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
	o Add explicit references to BNF syntax and rules imported from		o Add explicit references to BNF syntax and rules imported from
	other parts of the specification.		other parts of the specification.
	D.4. Since draft-ietf-httpbis-p5-range-02		D.4. Since draft-ietf-httpbis-p5-range-02
	Ongoing work on IANA Message Header Registration		Ongoing work on IANA Message Header Field Registration
	(<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):		(<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
	o Reference RFC 3984, and update header registrations for headers		o Reference RFC 3984, and update header field registrations for
	defined in this document.		headers defined in this document.
	D.5. Since draft-ietf-httpbis-p5-range-03		D.5. Since draft-ietf-httpbis-p5-range-03
	D.6. Since draft-ietf-httpbis-p5-range-04		D.6. Since draft-ietf-httpbis-p5-range-04
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/133>: "multipart/		o <http://tools.ietf.org/wg/httpbis/trac/ticket/133>: "multipart/
	byteranges minimum number of parts"		byteranges minimum number of parts"
	Ongoing work on ABNF conversion		Ongoing work on ABNF conversion
	(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):		(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
	o Use "/" instead of "|" for alternatives.		o Use "/" instead of "|" for alternatives.
	o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional		o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
	whitespace ("OWS") and required whitespace ("RWS").		whitespace ("OWS") and required whitespace ("RWS").
	o Rewrite ABNFs to spell out whitespace rules, factor out header		o Rewrite ABNFs to spell out whitespace rules, factor out header
	value format definitions.		field value format definitions.
	D.7. Since draft-ietf-httpbis-p5-range-05		D.7. Since draft-ietf-httpbis-p5-range-05
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/142>: "State base		o <http://tools.ietf.org/wg/httpbis/trac/ticket/142>: "State base
	for *-byte-pos and suffix-length"		for *-byte-pos and suffix-length"
	Ongoing work on Custom Ranges		Ongoing work on Custom Ranges
	(<http://tools.ietf.org/wg/httpbis/trac/ticket/85>):		(<http://tools.ietf.org/wg/httpbis/trac/ticket/85>):
	skipping to change at page 24, line 16		skipping to change at page 23, line 16
	entity / representation / variant terminology"		entity / representation / variant terminology"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider		o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider
	removing the 'changes from 2068' sections"		removing the 'changes from 2068' sections"
	Ongoing work on Custom Ranges		Ongoing work on Custom Ranges
	(<http://tools.ietf.org/wg/httpbis/trac/ticket/85>):		(<http://tools.ietf.org/wg/httpbis/trac/ticket/85>):
	o Add IANA registry.		o Add IANA registry.
			D.13. Since draft-ietf-httpbis-p5-range-11
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/217>: "Caches can't
			be required to serve ranges"
	Index		Index
	2		2
	206 Partial Content (status code) 7		206 Partial Content (status code) 6
	4		4
	416 Requested Range Not Satisfiable (status code) 8		416 Requested Range Not Satisfiable (status code) 7
	A		A
	Accept-Ranges header 9		Accept-Ranges header 8
	C		C
	Content-Range header 9		Content-Range header 8
	G		G
	Grammar		Grammar
	Accept-Ranges 9		Accept-Ranges 8
	Accept-Ranges-v 9		Accept-Ranges-v 8
	acceptable-ranges 9		acceptable-ranges 8
	byte-content-range-spec 9		byte-content-range-spec 8
	byte-range-resp-spec 9		byte-range-resp-spec 8
	byte-range-set 12		byte-range-set 11
	byte-range-spec 12		byte-range-spec 11
	byte-ranges-specifier 12		byte-ranges-specifier 11
	bytes-unit 6		bytes-unit 5
	Content-Range 9		Content-Range 8
	content-range-spec 9		content-range-spec 8
	Content-Range-v 9		Content-Range-v 8
	first-byte-pos 12		first-byte-pos 11
	If-Range 12		If-Range 11
	If-Range-v 12		If-Range-v 11
	instance-length 9		instance-length 8
	last-byte-pos 12		last-byte-pos 11
	other-range-unit 6		other-range-unit 5
	Range 14		Range 13
	range-unit 6		range-unit 5
	ranges-specifier 12		ranges-specifier 11
	suffix-byte-range-spec 13		suffix-byte-range-spec 12
	suffix-length 13		suffix-length 12
	H		H
	Headers		Headers
	Accept-Ranges 9		Accept-Ranges 8
	Content-Range 9		Content-Range 8
	If-Range 11		If-Range 10
	Range 12		Range 11
	I		I
	If-Range header 11		If-Range header 10
	M		M
	Media Type		Media Type
	multipart/byteranges 17		multipart/byteranges 16
	multipart/x-byteranges 20		multipart/x-byteranges 19
	multipart/byteranges Media Type 17		multipart/byteranges Media Type 16
	multipart/x-byteranges Media Type 20		multipart/x-byteranges Media Type 19
	R		R
	Range header 12		Range header 11
	S		S
	Status Codes		Status Codes
	206 Partial Content 7		206 Partial Content 6
	416 Requested Range Not Satisfiable 8		416 Requested Range Not Satisfiable 7
	Authors' Addresses		Authors' Addresses
	Roy T. Fielding (editor)		Roy T. Fielding (editor)
	Day Software		Day Software
	23 Corporate Plaza DR, Suite 280		23 Corporate Plaza DR, Suite 280
	Newport Beach, CA 92660		Newport Beach, CA 92660
	USA		USA
	Phone: +1-949-706-5300		Phone: +1-949-706-5300
End of changes. 42 change blocks.
	146 lines changed or deleted		153 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/