draft-ietf-httpbis-p5-range-07.txt		draft-ietf-httpbis-p5-range-08.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 One Laptop per Child		Intended status: Standards Track One Laptop per Child
	Expires: January 14, 2010 J. Mogul		Expires: April 29, 2010 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
	July 13, 2009		October 26, 2009
	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-07		draft-ietf-httpbis-p5-range-08
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79. This document may contain material		provisions of BCP 78 and BCP 79. This document may contain material
	from IETF Documents or IETF Contributions published or made publicly		from IETF Documents or IETF Contributions published or made publicly
	available before November 10, 2008. The person(s) controlling the		available before November 10, 2008. The person(s) controlling the
	copyright in some of this material may not have granted the IETF		copyright in some of this material may not have granted the IETF
	Trust the right to allow modifications of such material outside the		Trust the right to allow modifications of such material outside the
	IETF Standards Process. Without obtaining an adequate license from		IETF Standards Process. Without obtaining an adequate license from
	skipping to change at page 2, line 10		skipping to change at page 2, line 10
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on January 14, 2010.		This Internet-Draft will expire on April 29, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 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 in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 42		skipping to change at page 2, line 42
	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/11> and related		at <http://tools.ietf.org/wg/httpbis/trac/report/11> 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.8.		The changes in this draft are summarized in Appendix D.9.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4		1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
	1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5		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 . . . . . . . . . . . . . . . . . . . . 5		Specification . . . . . . . . . . . . . . . . . . . . 5
	2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 5
	skipping to change at page 3, line 26		skipping to change at page 3, line 26
	3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 6		3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 6
	4. Combining Ranges . . . . . . . . . . . . . . . . . . . . . . . 7		4. Combining Ranges . . . . . . . . . . . . . . . . . . . . . . . 7
	5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 7		5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 7
	5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7		5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7
	5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 8		5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 8
	5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 10		5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 10
	5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 11		5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 11		5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 11
	5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 13		5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 13
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	6.1. Message Header Registration . . . . . . . . . . . . . . . 14		6.1. Status Code Registration . . . . . . . . . . . . . . . . . 14
			6.2. Message Header Registration . . . . . . . . . . . . . . . 14
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 14		7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 14		9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
	9.2. Informative References . . . . . . . . . . . . . . . . . . 15		9.2. Informative References . . . . . . . . . . . . . . . . . . 15
	Appendix A. Internet Media Type multipart/byteranges . . . . . . 15		Appendix A. Internet Media Type multipart/byteranges . . . . . . 16
	Appendix B. Compatibility with Previous Versions . . . . . . . . 17		Appendix B. Compatibility with Previous Versions . . . . . . . . 18
	B.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 17		B.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 18
	B.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 18		B.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 19
	Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 18		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) . . . . . . . . . . . . . . . . . . . . 19		publication) . . . . . . . . . . . . . . . . . . . . 20
	D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 19		D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 20
	D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 20		D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 21
	D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 20		D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 21
	D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 20		D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 21
	D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 20		D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 21
	D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 20		D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 21
	D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 21		D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 22
	D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 21		D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 22
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21		D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
	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 5, line 21		skipping to change at page 5, line 21
	The core rules below are defined in Section 1.2.2 of [Part1]:		The core rules below are defined in Section 1.2.2 of [Part1]:
	token = <token, defined in [Part1], Section 1.2.2>		token = <token, defined in [Part1], Section 1.2.2>
	OWS = <OWS, defined in [Part1], Section 1.2.2>		OWS = <OWS, defined in [Part1], Section 1.2.2>
	1.2.2. ABNF Rules defined in other Parts of the Specification		1.2.2. ABNF Rules defined in other Parts of the Specification
	The ABNF rules below are defined in other parts:		The ABNF rules below are defined in other parts:
	HTTP-date = <HTTP-date, defined in [Part1], Section 3.2>		HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
	entity-tag = <entity-tag, defined in [Part4], Section 2>		entity-tag = <entity-tag, defined in [Part4], Section 2>
	2. Range Units		2. Range Units
	HTTP/1.1 allows a client to request that only part (a range of) the		HTTP/1.1 allows a client to request that only part (a range of) the
	response entity be included within the response. HTTP/1.1 uses range		response entity be included within the response. HTTP/1.1 uses range
	units in the Range (Section 5.4) and Content-Range (Section 5.2)		units in the Range (Section 5.4) and Content-Range (Section 5.2)
	header fields. An entity can be broken down into subranges according		header fields. An entity can be broken down into subranges according
	to various structural units.		to various structural units.
	skipping to change at page 7, line 44		skipping to change at page 7, line 44
	This section defines the syntax and semantics of HTTP/1.1 header		This section defines the syntax and semantics of HTTP/1.1 header
	fields related to range requests and partial responses.		fields related to range requests and partial responses.
	For entity-header fields, both sender and recipient refer to either		For entity-header fields, both sender and recipient refer to either
	the client or the server, depending on who sends and who receives the		the client or the server, depending on who sends and who receives the
	entity.		entity.
	5.1. Accept-Ranges		5.1. Accept-Ranges
	The response-header "Accept-Ranges" field allows the server to		The "Accept-Ranges" response-header field allows a resource to
	indicate its acceptance of range requests for a resource:		indicate its acceptance of range requests.
	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 for the resource involved. Range
	skipping to change at page 8, line 21		skipping to change at page 8, line 21
	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
	The entity-header "Content-Range" is sent with a partial entity-body		The "Content-Range" entity-header field is sent with a partial
	to specify where in the full entity-body the partial body should be		entity-body to specify where in the full entity-body the partial body
	applied. Range units are defined in Section 2.		should be applied. Range units are defined in Section 2.
	Content-Range = "Content-Range" ":" OWS Content-Range-v		Content-Range = "Content-Range" ":" OWS Content-Range-v
	Content-Range-v = content-range-spec		Content-Range-v = content-range-spec
	content-range-spec = byte-content-range-spec		content-range-spec = byte-content-range-spec
	/ other-content-range-spec		/ other-content-range-spec
	byte-content-range-spec = bytes-unit SP		byte-content-range-spec = bytes-unit SP
	byte-range-resp-spec "/"		byte-range-resp-spec "/"
	( instance-length / "*" )		( instance-length / "*" )
	skipping to change at page 10, line 14		skipping to change at page 10, line 14
	media type used for this purpose is "multipart/byteranges" as defined		media type used for this purpose is "multipart/byteranges" as defined
	in Appendix A. See Appendix B.1 for a compatibility issue.		in Appendix A. See Appendix B.1 for a compatibility issue.
	A response to a request for a single range MUST NOT be sent using the		A response to a request for a single range MUST NOT be sent using the
	multipart/byteranges media type. A response to a request for		multipart/byteranges media type. A response to a request for
	multiple ranges, whose result is a single range, MAY be sent as a		multiple ranges, whose result is a single range, MAY be sent as a
	multipart/byteranges media type with one part. A client that cannot		multipart/byteranges media type with one part. A client that cannot
	decode a multipart/byteranges message MUST NOT ask for multiple		decode a multipart/byteranges message MUST NOT ask for multiple
	ranges in a single request.		ranges in a single request.
	When a client requests multiple byte-ranges in one request, the		When a client requests multiple ranges in one request, the server
	server SHOULD return them in the order that they appeared in the		SHOULD return them in the order that they appeared in the request.
	request.
	If the server ignores a byte-range-spec because it is syntactically		If the server ignores a byte-range-spec because it is syntactically
	invalid, the server SHOULD treat the request as if the invalid Range		invalid, the server SHOULD treat the request as if the invalid Range
	header field did not exist. (Normally, this means return a 200		header field did not exist. (Normally, this means return a 200
	response containing the full entity).		response containing the full entity).
	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
	skipping to change at page 10, line 45		skipping to change at page 10, line 44
	5.3. If-Range		5.3. If-Range
	If a client has a partial copy of an entity in its cache, and wishes		If a client has a partial copy of an entity in its cache, and wishes
	to have an up-to-date copy of the entire entity in its cache, it		to have an up-to-date copy of the entire entity in its cache, it
	could use the Range request-header with a conditional GET (using		could use the Range request-header with a conditional GET (using
	either or both of If-Unmodified-Since and If-Match.) However, if the		either or both of If-Unmodified-Since and If-Match.) However, if the
	condition fails because the entity has been modified, the client		condition fails because the entity has been modified, the client
	would then have to make a second request to obtain the entire current		would then have to make a second request to obtain the entire current
	entity-body.		entity-body.
	The request header "If-Range" allows a client to "short-circuit" the		The "If-Range" request-header field allows a client to "short-
	second request. Informally, its meaning is `if the entity is		circuit" the second request. Informally, its meaning is `if the
	unchanged, send me the part(s) that I am missing; otherwise, send me		entity is unchanged, send me the part(s) that I am missing;
	the entire new entity'.		otherwise, send me the entire new entity'.
	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 an entity, but does have a Last-		If the client has no entity tag for an entity, but does have a Last-
	Modified date, it MAY use that date in an If-Range header. (The		Modified date, it MAY use that date in an If-Range header. (The
	server can distinguish between a valid HTTP-date and any form of		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 SHOULD only be used together with a Range header, and MUST be
	ignored if the request does not include a Range header, or if the		ignored if the request does not include a Range header, or if the
	server does not support the sub-range operation.		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 matches the current
	entity tag for the entity, then the server SHOULD provide the		cache validator for the entity, then the server SHOULD provide the
	specified sub-range of the entity using a 206 (Partial Content)		specified sub-range of the entity using a 206 (Partial Content)
	response. If the entity tag does not match, then the server SHOULD		response. If the cache validator does not match, then the server
	return the entire entity using a 200 (OK) response.		SHOULD return the entire entity using a 200 (OK) response.
	5.4. Range		5.4. Range
	5.4.1. Byte Ranges		5.4.1. Byte Ranges
	Since all HTTP entities are represented in HTTP messages as sequences		Since all HTTP entities are represented in HTTP messages as sequences
	of bytes, the concept of a byte range is meaningful for any HTTP		of bytes, the concept of a byte range is meaningful for any HTTP
	entity. (However, not all clients and servers need to support byte-		entity. (However, not all clients and servers need to support byte-
	range operations.)		range operations.)
	skipping to change at page 13, line 12		skipping to change at page 13, line 12
	bytes=0-0,-1		bytes=0-0,-1
	o Several legal but not canonical specifications of the second 500		o Several legal but not canonical specifications of the second 500
	bytes (byte offsets 500-999, inclusive):		bytes (byte offsets 500-999, inclusive):
	bytes=500-600,601-999		bytes=500-600,601-999
	bytes=500-700,601-999		bytes=500-700,601-999
	5.4.2. Range Retrieval Requests		5.4.2. Range Retrieval Requests
	HTTP retrieval requests using conditional or unconditional GET		The "Range" request-header field defines the GET method (conditional
	methods MAY request one or more sub-ranges of the entity, instead of		or not) to request one or more sub-ranges of the response entity-
	the entire entity, using the Range request header, which applies to		body, instead of the entire entity body.
	the entity returned as the result of the request:
	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 = 1*CHAR		other-ranges-specifier = other-range-unit "=" other-range-set
			other-range-set = 1*CHAR
	A server MAY ignore the Range header. However, HTTP/1.1 origin		A server MAY ignore the Range header. 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
	entities.		entities.
	If the server supports the Range header and the specified range or		If the server supports the Range header and the specified range or
	ranges are appropriate for the entity:		ranges are appropriate for the entity:
	skipping to change at page 14, line 7		skipping to change at page 14, line 7
	header (see Section 5.3) in addition to the Range header.		header (see Section 5.3) in addition to the Range header.
	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 entity in		the request to an inbound server, and receives an entire entity in
	reply, it SHOULD only return the requested range to its client. It		reply, it SHOULD only return the requested range to its client. It
	SHOULD store the entire received response in its cache if that is		SHOULD store the entire received response in its cache if that is
	consistent with its cache allocation policies.		consistent with its cache allocation policies.
	6. IANA Considerations		6. IANA Considerations
	6.1. Message Header Registration		6.1. Status Code Registration
			The HTTP Status Code Registry located at
			<http://www.iana.org/assignments/http-status-codes> should be updated
			with the registrations below:
			+-------+---------------------------------+-------------+
			| Value | Description | Reference |
			+-------+---------------------------------+-------------+
			| 206 | Partial Content | Section 3.1 |
			| 416 | Requested Range Not Satisfiable | Section 3.2 |
			+-------+---------------------------------+-------------+
			6.2. Message Header Registration
	The Message Header Registry located at <http://www.iana.org/		The Message Header Registry located at <http://www.iana.org/
	assignments/message-headers/message-header-index.html> should be		assignments/message-headers/message-header-index.html> should be
	updated with the permanent registrations below (see [RFC3864]):		updated with the permanent registrations below (see [RFC3864]):
	+-------------------+----------+----------+-------------+		+-------------------+----------+----------+-------------+
	| Header Field Name | Protocol | Status | Reference |		| Header Field Name | Protocol | Status | Reference |
	+-------------------+----------+----------+-------------+		+-------------------+----------+----------+-------------+
	| Accept-Ranges | http | standard | Section 5.1 |		| Accept-Ranges | http | standard | Section 5.1 |
	| Content-Range | http | standard | Section 5.2 |		| Content-Range | http | standard | Section 5.2 |
	skipping to change at page 14, line 46		skipping to change at page 15, line 12
	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-07		and Message Parsing", draft-ietf-httpbis-p1-messaging-08
	(work in progress), July 2009.		(work in progress), October 2009.
	[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part3] 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 3: Message Payload		and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
	and Content Negotiation", draft-ietf-httpbis-p3-payload-07		and Content Negotiation", draft-ietf-httpbis-p3-payload-08
	(work in progress), July 2009.		(work in progress), October 2009.
	[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-07 (work in		Requests", draft-ietf-httpbis-p4-conditional-08 (work in
	progress), July 2009.		progress), October 2009.
	[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part6] 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.,
	Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part		Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
	6: Caching", draft-ietf-httpbis-p6-cache-07 (work in		6: Caching", draft-ietf-httpbis-p6-cache-08 (work in
	progress), July 2009.		progress), October 2009.
	[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 16, line 6		skipping to change at page 16, line 17
	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 an HTTP 206 (Partial Content) response message includes the
	content of multiple ranges (a response to a request for multiple non-		content of multiple ranges (a response to a request for multiple non-
	overlapping ranges), these are transmitted as a multipart message-		overlapping ranges), these are transmitted as a multipart message-
	body ([RFC2046], Section 5.1). The media type for this purpose is		body ([RFC2046], Section 5.1). The media type for this purpose is
	called "multipart/byteranges". The following is to be registered		called "multipart/byteranges". The following is to be registered
	with IANA [RFC4288].		with IANA [RFC4288].
			Note: Despite the name "multipart/byteranges" is not limited to
			the byte ranges only.
	The multipart/byteranges media type includes one or more parts, each		The multipart/byteranges media type includes one or more parts, each
	with its own Content-Type and Content-Range fields. The required		with its own Content-Type and Content-Range fields. The required
	boundary parameter specifies the boundary string used to separate		boundary parameter specifies the boundary string used to separate
	each body-part.		each body-part.
	Type name: multipart		Type name: multipart
	Subtype name: byteranges		Subtype name: byteranges
	Required parameters: boundary		Required parameters: boundary
	skipping to change at page 17, line 22		skipping to change at page 18, line 4
	Content-type: application/pdf		Content-type: application/pdf
	Content-range: bytes 500-999/8000		Content-range: bytes 500-999/8000
	...the first range...		...the first range...
	--THIS_STRING_SEPARATES		--THIS_STRING_SEPARATES
	Content-type: application/pdf		Content-type: application/pdf
	Content-range: bytes 7000-7999/8000		Content-range: bytes 7000-7999/8000
	...the second range		...the second range
	--THIS_STRING_SEPARATES--		--THIS_STRING_SEPARATES--
			Other example:
			HTTP/1.1 206 Partial Content
			Date: Tue, 14 Nov 1995 06:25:24 GMT
			Last-Modified: Tue, 14 July 04:58:08 GMT
			Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
			--THIS_STRING_SEPARATES
			Content-type: video/example
			Content-range: exampleunit 1.2-4.3/25
			...the first range...
			--THIS_STRING_SEPARATES
			Content-type: video/example
			Content-range: exampleunit 11.2-14.3/25
			...the second range
			--THIS_STRING_SEPARATES--
	Notes:		Notes:
	1. Additional CRLFs may precede the first boundary string in the		1. Additional CRLFs may precede the first boundary string in the
	entity.		entity.
	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 18, line 34		skipping to change at page 19, line 34
	(Appendix A)		(Appendix A)
	Appendix C. Collected ABNF		Appendix C. Collected ABNF
	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
	Content-Range = "Content-Range:" OWS Content-Range-v		Content-Range = "Content-Range:" OWS Content-Range-v
	Content-Range-v = content-range-spec		Content-Range-v = content-range-spec
	HTTP-date = <HTTP-date, defined in [Part1], Section 3.2>		HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
	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
	OWS = <OWS, defined in [Part1], Section 1.2.2>		OWS = <OWS, defined in [Part1], Section 1.2.2>
	Range = "Range:" OWS Range-v		Range = "Range:" OWS Range-v
	Range-v = byte-ranges-specifier / other-ranges-specifier		Range-v = byte-ranges-specifier / other-ranges-specifier
	acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS		acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS
	skipping to change at page 19, line 24		skipping to change at page 20, line 24
	entity-tag = <entity-tag, defined in [Part4], Section 2>		entity-tag = <entity-tag, defined in [Part4], Section 2>
	first-byte-pos = 1*DIGIT		first-byte-pos = 1*DIGIT
	instance-length = 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-spec = other-range-unit SP other-range-resp-spec
	other-range-resp-spec = *CHAR		other-range-resp-spec = *CHAR
			other-range-set = 1*CHAR
	other-range-unit = token		other-range-unit = token
	other-ranges-specifier = 1*CHAR		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 1.2.2>		token = <token, defined in [Part1], Section 1.2.2>
	ABNF diagnostics:		ABNF diagnostics:
	skipping to change at page 21, line 38		skipping to change at page 22, line 38
	o Add appendix containing collected and expanded ABNF, reorganize		o Add appendix containing collected and expanded ABNF, reorganize
	ABNF introduction.		ABNF introduction.
	D.8. Since draft-ietf-httpbis-p5-range-06		D.8. Since draft-ietf-httpbis-p5-range-06
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for		o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for
	numeric protocol elements"		numeric protocol elements"
			D.9. Since draft-ietf-httpbis-p5-range-07
			Closed issues:
			o Fixed discrepancy in the If-Range definition about allowed
			validators.
			o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/150>:
			"multipart/byteranges for custom range units"
			o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/151>: "range
			unit missing from other-ranges-specifier in Range header"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA
			registrations for optional status codes"
	Index		Index
	2		2
	206 Partial Content (status code) 6		206 Partial Content (status code) 6
	4		4
	416 Requested Range Not Satisfiable (status code) 6		416 Requested Range Not Satisfiable (status code) 6
	A		A
	Accept-Ranges header 7		Accept-Ranges header 7
	skipping to change at page 22, line 42		skipping to change at page 24, line 8
	Accept-Ranges 7		Accept-Ranges 7
	Content-Range 8		Content-Range 8
	If-Range 10		If-Range 10
	Range 11		Range 11
	I		I
	If-Range header 10		If-Range header 10
	M		M
	Media Type		Media Type
	multipart/byteranges 15		multipart/byteranges 16
	multipart/x-byteranges 17		multipart/x-byteranges 18
	multipart/byteranges Media Type 15		multipart/byteranges Media Type 16
	multipart/x-byteranges Media Type 17		multipart/x-byteranges Media Type 18
	R		R
	Range header 11		Range header 11
	S		S
	Status Codes		Status Codes
	206 Partial Content 6		206 Partial Content 6
	416 Requested Range Not Satisfiable 6		416 Requested Range Not Satisfiable 6
	Authors' Addresses		Authors' Addresses
End of changes. 30 change blocks.
	60 lines changed or deleted		112 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/