draft-ietf-httpbis-p5-range-13.txt		draft-ietf-httpbis-p5-range-14.txt
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis Working Group R. Fielding, Ed.
	Internet-Draft Adobe		Internet-Draft Adobe
	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: September 15, 2011 J. Mogul		Expires: October 20, 2011 J. Mogul
	HP		HP
	H. Frystyk		H. Frystyk
	Microsoft		Microsoft
	L. Masinter		L. Masinter
	Adobe		Adobe
	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
	March 14, 2011		April 18, 2011
	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-13		draft-ietf-httpbis-p5-range-14
	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), which is archived at
	at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related		<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
			The current issues list is 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.14.		The changes in this draft are summarized in Appendix D.15.
	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 September 15, 2011.		This Internet-Draft will expire on October 20, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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 24		skipping to change at page 3, line 27
	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. Status Code Registration . . . . . . . . . . . . . . . . . 14		6.1. Status Code Registration . . . . . . . . . . . . . . . . . 14
	6.2. Header Field Registration . . . . . . . . . . . . . . . . 14		6.2. Header Field Registration . . . . . . . . . . . . . . . . 14
	6.3. Range Specifier Registration . . . . . . . . . . . . . . . 15		6.3. Range Specifier Registration . . . . . . . . . . . . . . . 15
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 15		7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 15		9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
	9.2. Informative References . . . . . . . . . . . . . . . . . . 16		9.2. Informative References . . . . . . . . . . . . . . . . . . 16
	Appendix A. Internet Media Type multipart/byteranges . . . . . . 16		Appendix A. Internet Media Type multipart/byteranges . . . . . . 16
	Appendix B. Compatibility with Previous Versions . . . . . . . . 19		Appendix B. Compatibility with Previous Versions . . . . . . . . 19
	B.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 19		B.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 19
	Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 19		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) . . . . . . . . . . . . . . . . . . . . 20		publication) . . . . . . . . . . . . . . . . . . . . 21
	D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 20		D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 21
	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 . . . . . . . . . . . 21		D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 21
	D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 21		D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 21
	D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 21		D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 22
	D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 21		D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 22
	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 . . . . . . . . . . . 22		D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 22
	D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 22		D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 23
	D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 22		D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 23
	D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 22		D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 23
	D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 22		D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 23
	D.13. Since draft-ietf-httpbis-p5-range-11 . . . . . . . . . . . 23		D.13. Since draft-ietf-httpbis-p5-range-11 . . . . . . . . . . . 23
	D.14. Since draft-ietf-httpbis-p5-range-12 . . . . . . . . . . . 23		D.14. Since draft-ietf-httpbis-p5-range-12 . . . . . . . . . . . 24
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23		D.15. Since draft-ietf-httpbis-p5-range-13 . . . . . . . . . . . 24
			Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 24		skipping to change at page 5, line 24
	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 6.1>		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>
	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
	representation be included within the response. HTTP/1.1 uses range		representation 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. A representation can be broken down into subranges		header fields. A representation can be broken down into subranges
	according to various structural units.		according to various structural units.
	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
	skipping to change at page 5, line 50		skipping to change at page 5, line 50
	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 field (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 Range 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:
	o Name		o Name
	o Description		o Description
	o Pointer to specification text		o Pointer to specification text
	skipping to change at page 7, line 42		skipping to change at page 7, line 42
	If a cache has a stored non-empty set of subranges for a		If a cache has a stored non-empty set of subranges for a
	representation, and an incoming response transfers another subrange,		representation, and an incoming response transfers another subrange,
	the cache MAY combine the new subrange with the existing set if both		the cache MAY combine the new subrange with the existing set if both
	the following conditions are met:		the following conditions are met:
	o Both the incoming response and the cache entry have a cache		o Both the incoming response and the cache entry have a cache
	validator.		validator.
	o The two cache validators match using the strong comparison		o The two cache validators match using the strong comparison
	function (see Section 4 of [Part4]).		function (see Section 2.2.2 of [Part4]).
	If either requirement is not met, the cache MUST use only the most		If either requirement is not met, the cache MUST use only the most
	recent partial response (based on the Date values transmitted with		recent partial response (based on the Date values transmitted with
	every response, and using the incoming response if these values are		every response, and using the incoming response if these values are
	equal or missing), and MUST discard the other partial information.		equal or missing), and MUST discard the other partial information.
	5. Header Field Definitions		5. Header Field Definitions
	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.
	5.1. Accept-Ranges		5.1. Accept-Ranges
	The "Accept-Ranges" header field allows a resource to indicate its		The "Accept-Ranges" header field allows a resource to indicate its
	acceptance of range requests.		acceptance of range requests.
	Accept-Ranges = "Accept-Ranges" ":" OWS Accept-Ranges-v		Accept-Ranges = 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 field for the resource involved.		without having received this header field for the resource involved.
	Range units are defined in Section 2.		Range units are defined in Section 2.
	skipping to change at page 8, line 37		skipping to change at page 8, line 36
	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 "Content-Range" header field is sent with a partial		The "Content-Range" header field is sent with a partial
	representation to specify where in the full representation the		representation to specify where in the full representation the
	payload body is intended to be applied.		payload body is intended to be applied.
	Range units are defined in Section 2.		Range units are defined in Section 2.
	Content-Range = "Content-Range" ":" OWS Content-Range-v		Content-Range = 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 / "*" )
	byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)		byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)
	/ "*"		/ "*"
	skipping to change at page 11, line 14		skipping to change at page 11, line 11
	(using either or both of If-Unmodified-Since and If-Match.) However,		(using either or both of If-Unmodified-Since and If-Match.) However,
	if the condition fails because the representation has been modified,		if the condition fails because the representation has been modified,
	the client would then have to make a second request to obtain the		the client would then have to make a second request to obtain the
	entire current representation.		entire current representation.
	The "If-Range" header field allows a client to "short-circuit" the		The "If-Range" header field allows a client to "short-circuit" the
	second request. Informally, its meaning is "if the representation is		second request. Informally, its meaning is "if the representation is
	unchanged, send me the part(s) that I am missing; otherwise, send me		unchanged, send me the part(s) that I am missing; otherwise, send me
	the entire new representation".		the entire new representation".
	If-Range = "If-Range" ":" OWS If-Range-v		If-Range = entity-tag / HTTP-date
	If-Range-v = entity-tag / HTTP-date
			Only a strong validator (Section 2.2.2 of [Part4]) is usable for
			range retrieval, since otherwise the client might end up with an
			internally inconsistent representation. Clients MUST NOT use weak
			validators in range requests. A cache or origin server receiving a
			conditional range request MUST use the strong comparison function to
			evaluate the condition.
	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 field.		Last-Modified date, it MAY use that date in an If-Range header field.
	(The 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 field SHOULD only be used together with a Range header field,		header field SHOULD only be used together with a Range header field,
	and MUST be ignored if the request does not include a Range header		and MUST be ignored if the request does not include a Range header
	field, or if the server does not support the sub-range operation.		field, or if the server does not support the sub-range operation.
			If a client wishes to perform a sub-range retrieval on a value for
			which it has only a Last-Modified time and no opaque validator, it
			MAY do this only if the Last-Modified time is strong in the sense
			described in Section 2.1.2 of [Part4].
	If the entity-tag given in the If-Range header field matches the		If the entity-tag given in the If-Range header field matches the
	current cache validator for the representation, then the server		current cache validator for the representation, then the server
	SHOULD provide the specified sub-range of the representation using a		SHOULD provide the specified sub-range of the representation using a
	206 (Partial Content) response. If the cache validator does not		206 (Partial Content) response. If the cache validator does not
	match, then the server SHOULD return the entire representation using		match, then the server SHOULD return the entire representation using
	a 200 (OK) response.		a 200 (OK) response.
	5.4. Range		5.4. Range
	5.4.1. Byte Ranges		5.4.1. Byte Ranges
	skipping to change at page 13, line 33		skipping to change at page 13, line 40
	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
	The "Range" header field defines the GET method (conditional or not)		The "Range" header field defines the GET method (conditional or not)
	to request one or more sub-ranges of the response representation		to request one or more sub-ranges of the response representation
	body, instead of the entire representation body.		body, instead of the entire representation body.
	Range = "Range" ":" OWS Range-v		Range = byte-ranges-specifier / other-ranges-specifier
	Range-v = byte-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 field. 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 field and the specified range		If the server supports the Range header field and the specified range
	skipping to change at page 15, line 38		skipping to change at page 16, line 4
	8. Acknowledgments		8. Acknowledgments
	Most of the specification of ranges is based on work originally done		Most of the specification of ranges is based on work originally done
	by Ari Luotonen and John Franks, with additional input from Steve		by Ari Luotonen and John Franks, with additional input from Steve
	Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin		Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin
	Hamilton, Koen Holtman, Shel Kaplan, Paul Leach, Alex Lopez-Ortiz,		Hamilton, Koen Holtman, Shel Kaplan, Paul Leach, Alex Lopez-Ortiz,
	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-13		and Message Parsing", draft-ietf-httpbis-p1-messaging-14
	(work in progress), March 2011.		(work in progress), April 2011.
	[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-13 (work in		Requests", draft-ietf-httpbis-p4-conditional-14 (work in
	progress), March 2011.		progress), April 2011.
	[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 17		skipping to change at page 19, line 17
	x-byteranges, which is almost, but not quite compatible with the		x-byteranges, which is almost, but not quite compatible with the
	version documented in HTTP/1.1.		version documented in HTTP/1.1.
	Appendix B. Compatibility with Previous Versions		Appendix B. Compatibility with Previous Versions
	B.1. Changes from RFC 2616		B.1. Changes from RFC 2616
	Clarify that it is not ok to use a weak cache validator in a 206		Clarify that it is not ok to use a weak cache validator in a 206
	response. (Section 3.1)		response. (Section 3.1)
			Change ABNF productions for header fields to only define the field
			value. (Section 5)
	Clarify that multipart/byteranges can consist of a single part.		Clarify that multipart/byteranges can consist of a single part.
	(Appendix A)		(Appendix A)
	Appendix C. Collected ABNF		Appendix C. Collected ABNF
			Accept-Ranges = acceptable-ranges
	Accept-Ranges = "Accept-Ranges:" OWS Accept-Ranges-v		Content-Range = content-range-spec
	Accept-Ranges-v = acceptable-ranges
	Content-Range = "Content-Range:" OWS Content-Range-v
	Content-Range-v = content-range-spec
	HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>		HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
	If-Range = "If-Range:" OWS If-Range-v		If-Range = 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 = 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
	range-unit ] ) ) / "none"		range-unit ] ) ) / "none"
	byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" (		byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" (
	instance-length / "*" )		instance-length / "*" )
	byte-range-resp-spec = ( first-byte-pos "-" last-byte-pos ) / "*"		byte-range-resp-spec = ( first-byte-pos "-" last-byte-pos ) / "*"
	byte-range-set = ( *( "," OWS ) byte-range-spec ) / (		byte-range-set = ( *( "," OWS ) byte-range-spec ) / (
	suffix-byte-range-spec *( OWS "," [ ( OWS byte-range-spec ) /		suffix-byte-range-spec *( OWS "," [ ( OWS byte-range-spec ) /
	suffix-byte-range-spec ] ) )		suffix-byte-range-spec ] ) )
	byte-range-spec = first-byte-pos "-" [ last-byte-pos ]		byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
	byte-ranges-specifier = bytes-unit "=" byte-range-set		byte-ranges-specifier = bytes-unit "=" byte-range-set
	bytes-unit = "bytes"		bytes-unit = "bytes"
	content-range-spec = byte-content-range-spec /		content-range-spec = byte-content-range-spec /
	other-content-range-spec		other-content-range-spec
	entity-tag = <entity-tag, defined in [Part4], Section 2>		entity-tag = <entity-tag, defined in [Part4], Section 2.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-set = 1*CHAR
	skipping to change at page 21, line 28		skipping to change at page 22, line 7
	D.4. Since draft-ietf-httpbis-p5-range-02		D.4. Since draft-ietf-httpbis-p5-range-02
	Ongoing work on IANA Message Header Field 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 field registrations for		o Reference RFC 3984, and update header field registrations for
	headers 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
			None.
	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>):
	skipping to change at page 23, line 30		skipping to change at page 24, line 12
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/217>: "Caches can't		o <http://tools.ietf.org/wg/httpbis/trac/ticket/217>: "Caches can't
	be required to serve ranges"		be required to serve ranges"
	D.14. Since draft-ietf-httpbis-p5-range-12		D.14. Since draft-ietf-httpbis-p5-range-12
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header		o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header
	Classification"		Classification"
			D.15. Since draft-ietf-httpbis-p5-range-13
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
			ABNFs for header fields"
	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) 7		416 Requested Range Not Satisfiable (status code) 7
	A		A
	Accept-Ranges header field 8		Accept-Ranges header field 8
	C		C
	Content-Range header field 8		Content-Range header field 8
	G		G
	Grammar		Grammar
	Accept-Ranges 8		Accept-Ranges 8
	Accept-Ranges-v 8
	acceptable-ranges 8		acceptable-ranges 8
	byte-content-range-spec 8		byte-content-range-spec 8
	byte-range-resp-spec 8		byte-range-resp-spec 8
	byte-range-set 11		byte-range-set 12
	byte-range-spec 11		byte-range-spec 12
	byte-ranges-specifier 11		byte-ranges-specifier 12
	bytes-unit 5		bytes-unit 5
	Content-Range 8		Content-Range 8
	content-range-spec 8		content-range-spec 8
	Content-Range-v 8		first-byte-pos 12
	first-byte-pos 11
	If-Range 11		If-Range 11
	If-Range-v 11
	instance-length 8		instance-length 8
	last-byte-pos 11		last-byte-pos 12
	other-range-unit 5		other-range-unit 5
	Range 13		Range 13
	range-unit 5		range-unit 5
	ranges-specifier 11		ranges-specifier 12
	suffix-byte-range-spec 12		suffix-byte-range-spec 12
	suffix-length 12		suffix-length 12
	H		H
	Header Fields		Header Fields
	Accept-Ranges 8		Accept-Ranges 8
	Content-Range 8		Content-Range 8
	If-Range 10		If-Range 10
	Range 11		Range 11
End of changes. 37 change blocks.
	58 lines changed or deleted		72 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/