draft-ietf-httpbis-p5-range-00.txt		draft-ietf-httpbis-p5-range-01.txt
	Network Working Group R. Fielding, Ed.		Network Working Group R. Fielding, Ed.
	Internet-Draft Day Software		Internet-Draft Day Software
	Obsoletes: 2068, 2616 J. Gettys		Obsoletes: 2616 (if approved) J. Gettys
	(if approved) One Laptop per Child		Intended status: Standards Track One Laptop per Child
	Intended status: Standards Track J. Mogul		Expires: July 15, 2008 J. Mogul
	Expires: June 22, 2008 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
	December 20, 2007		Y. Lafon, Ed.
			W3C
			J. Reschke, Ed.
			greenbytes
			January 12, 2008
	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-00		draft-ietf-httpbis-p5-range-01
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 45		skipping to change at page 1, line 49
	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 June 22, 2008.		This Internet-Draft will expire on July 15, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	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)
	This version of the HTTP specification contains only minimal
	editorial changes from [RFC2616] (abstract, introductory paragraph,
	and authors' addresses). All other changes are due to partitioning
	the original into seven mostly independent parts. The intent is for
	readers of future drafts to able to use draft 00 as the basis for
	comparison when the WG makes later changes to the specification text.
	This draft will shortly be followed by draft 01 (containing the first
	round of changes that have already been agreed to on the mailing
	list). There is no point in reviewing this draft other than to
	verify that the partitioning has been done correctly. Roy T.
	Fielding, Yves Lafon, and Julian Reschke will be the editors after
	draft 00 is submitted.
	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://www3.tools.ietf.org/wg/httpbis/trac/report/11> and related		at <http://www.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://www3.tools.ietf.org/wg/httpbis/>.		<http://www.tools.ietf.org/wg/httpbis/>.
			This draft incorporates those issue resolutions that were either
			collected in the original RFC2616 errata list
			(<http://purl.org/NET/http-errata>), or which were agreed upon on the
			mailing list between October 2006 and November 2007 (as published in
			"draft-lafon-rfc2616bis-03").
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
			1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 4		3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5
	3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 4		3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 5
	3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 5		3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 6
	4. Combining Byte Ranges . . . . . . . . . . . . . . . . . . . . 5		4. Combining Byte Ranges . . . . . . . . . . . . . . . . . . . . 6
	5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 6		5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 6
	5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 6		5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7
	5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 7		5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 7
	5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 9		5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 9
	5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 9		5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 9		5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 10
	5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 11		5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 12
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 12		7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	Appendix A. Internet Media Type multipart/byteranges . . . . . . 13		9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
	Appendix B. Changes from RFC 2068 . . . . . . . . . . . . . . . . 14		9.2. Informative References . . . . . . . . . . . . . . . . . . 14
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15		Appendix A. Internet Media Type multipart/byteranges . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16		Appendix B. Compatibility with Previous Versions . . . . . . . . 15
	Intellectual Property and Copyright Statements . . . . . . . . . . 18		B.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 15
			B.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 16
			Appendix C. Change Log (to be removed by RFC Editor before
			publication) . . . . . . . . . . . . . . . . . . . . 16
			C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 16
			C.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 16
			Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
			Intellectual Property and Copyright Statements . . . . . . . . . . 21
	1. Introduction		1. Introduction
	This document will define aspects of HTTP related to range requests,		HTTP clients often encounter interrupted data transfers as a result
	partial responses, and the multipart/byteranges media type. Right		of cancelled requests or dropped connections. When a cache has
	now it only includes the extracted relevant sections of RFC 2616		stored a partial representation, it is desirable to request the
	[RFC2616] without edit.		remainder of that representation in a subsequent request rather than
			transfer the entire representation. There are also a number of Web
			applications that benefit from being able to request only a subset of
			a larger representation, such as a single page of a very large
			document or only part of an image to be rendered by a device with
			limited local storage.
			This document defines HTTP/1.1 range requests, partial responses, and
			the multipart/byteranges media type. The protocol for range requests
			is an OPTIONAL feature of HTTP, designed so resources or recipients
			that do not implement this feature can respond as if it is a normal
			GET request without impacting interoperability. Partial responses
			are indicated by a distinct status code to not be mistaken for full
			responses by intermediate caches that might not implement the
			feature.
			Although the HTTP range request mechanism is designed to allow for
			extensible range types, this specification only defines requests for
			byte ranges.
			1.1. Requirements
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in [RFC2119].
			An implementation is not compliant if it fails to satisfy one or more
			of the MUST or REQUIRED level requirements for the protocols it
			implements. An implementation that satisfies all the MUST or
			REQUIRED level and all the SHOULD level requirements for its
			protocols is said to be "unconditionally compliant"; one that
			satisfies all the MUST level requirements but not all the SHOULD
			level requirements for its protocols is said to be "conditionally
			compliant."
	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.
	range-unit = bytes-unit | other-range-unit		range-unit = bytes-unit | other-range-unit
	skipping to change at page 5, line 4		skipping to change at page 5, line 34
	The response MUST include the following header fields:		The response MUST include the following header fields:
	o Either a Content-Range header field (Section 5.2) indicating the		o Either a Content-Range header field (Section 5.2) indicating the
	range included with this response, or a multipart/byteranges		range included with this response, or a multipart/byteranges
	Content-Type including Content-Range fields for each part. If a		Content-Type including Content-Range fields for each part. If a
	Content-Length header field is present in the response, its value		Content-Length header field is present in the response, its value
	MUST match the actual number of OCTETs transmitted in the message-		MUST match the actual number of OCTETs transmitted in the message-
	body.		body.
	o Date		o Date
	o ETag and/or Content-Location, if the header would have been sent		o ETag and/or Content-Location, if the header would have been sent
	in a 200 response to the same request		in a 200 response to the same request
	o Expires, Cache-Control, and/or Vary, if the field-value might		o Expires, Cache-Control, and/or Vary, if the field-value might
	differ from that sent in any previous response for the same		differ from that sent in any previous response for the same
	variant		variant
	If the 206 response is the result of an If-Range request that used a		If the 206 response is the result of an If-Range request, the
	strong cache validator (see Section 4 of [Part4]), the response		response SHOULD NOT include other entity-headers. Otherwise, the
	SHOULD NOT include other entity-headers. If the response is the		response MUST include all of the entity-headers that would have been
	result of an If-Range request that used a weak validator, the		returned with a 200 (OK) response to the same request.
	response MUST NOT include other entity-headers; this prevents
	inconsistencies between cached entity-bodies and updated headers.
	Otherwise, the response MUST include all of the entity-headers that
	would have been returned with a 200 (OK) response to the 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 headers do not match exactly,
	see 4.		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 headers
	MUST NOT cache 206 (Partial) responses.		MUST NOT cache 206 (Partial Content) responses.
	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
	range-specifier values in this field overlap the current extent of		range-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. (For byte-ranges, this means that the first-		request-header field. (For byte-ranges, this means that the first-
	byte-pos of all of the byte-range-spec values were greater than the		byte-pos of all of the byte-range-spec values were greater than the
	current length of the selected resource.)		current length of the selected resource.)
	skipping to change at page 6, line 23		skipping to change at page 6, line 48
	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 4 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 all standard		This section defines the syntax and semantics of HTTP/1.1 header
	HTTP/1.1 header fields. For entity-header fields, both sender and		fields related to range requests and partial responses.
	recipient refer to either the client or the server, depending on who
	sends and who receives the entity.		For entity-header fields, both sender and recipient refer to either
			the client or the server, depending on who sends and who receives the
			entity.
	5.1. Accept-Ranges		5.1. Accept-Ranges
	The Accept-Ranges response-header field allows the server to indicate		The Accept-Ranges response-header field allows the server to indicate
	its acceptance of range requests for a resource:		its acceptance of range requests for a resource:
	Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges		Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges
	acceptable-ranges = 1#range-unit | "none"		acceptable-ranges = 1#range-unit | "none"
	Origin servers that accept byte-range requests MAY send		Origin servers that accept byte-range requests MAY send
	skipping to change at page 8, line 22		skipping to change at page 8, line 48
	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, and a Content-Length header
	showing the number of bytes actually transferred. For example,		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
	ranges), these are transmitted as a multipart message. The multipart		ranges), these are transmitted as a multipart message. The multipart
	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 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 byte-		decode a multipart/byteranges message MUST NOT ask for multiple byte-
	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 byte-ranges in one request, the
	server SHOULD return them in the order that they appeared in the		server SHOULD return them in the order that they appeared in the
	skipping to change at page 9, line 42		skipping to change at page 10, line 19
	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		entity tag 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 entity tag does not match, then the server SHOULD
	return the entire entity using a 200 (OK) response.		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-
	skipping to change at page 12, line 35		skipping to change at page 13, line 14
	7. Security Considerations		7. Security Considerations
	No additional security considerations have been identified beyond		No additional security considerations have been identified beyond
	those applicable to HTTP in general [Part1].		those applicable to HTTP in general [Part1].
	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.		Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin
			Hamilton, Koen Holtman, Shel Kaplan, Paul Leach, Alex Lopez-Ortiz,
	Based on an XML translation of RFC 2616 by Julian Reschke.		Larry Masinter, Jeff Mogul, Lou Montulli, David W. Morris, Luigi
			Rizzo, and Bill Weihl.
	9. References		9. 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., and T. Berners-Lee, "HTTP/1.1,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	part 1: URIs, Connections, and Message Parsing",		and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
	draft-ietf-httpbis-p1-messaging-00 (work in progress),		and Message Parsing", draft-ietf-httpbis-p1-messaging-01
	December 2007.		(work in progress), January 2008.
			[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
			Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
			and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
			and Content Negotiation", draft-ietf-httpbis-p3-payload-01
			(work in progress), January 2008.
	[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	part 4: Conditional Requests",		and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
	draft-ietf-httpbis-p4-conditional-00 (work in progress),		Requests", draft-ietf-httpbis-p4-conditional-01 (work in
	December 2007.		progress), January 2008.
			[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
			Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
			and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
			draft-ietf-httpbis-p6-cache-01 (work in progress),
			January 2008.
	[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
			Requirement Levels", BCP 14, RFC 2119, March 1997.
			9.2. Informative References
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext		Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.		Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
	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. The media type for this purpose is called "multipart/		body. The media type for this purpose is called "multipart/
	skipping to change at page 14, line 28		skipping to change at page 15, line 28
	Content-range: bytes 7000-7999/8000		Content-range: bytes 7000-7999/8000
	...the second range		...the second range
	--THIS_STRING_SEPARATES--		--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 RFC 2046 [RFC2046] permits the boundary string to be		2. Although [RFC2046] permits the boundary string to be quoted, some
	quoted, some existing implementations handle a quoted boundary		existing implementations handle a quoted boundary string
	string incorrectly.		incorrectly.
	3. A number of browsers and servers were coded to an early draft of		3. A number of browsers and servers were coded to an early draft of
	the byteranges specification to use a media type of multipart/		the byteranges specification to use a media type of multipart/
	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. Changes from RFC 2068		Appendix B. Compatibility with Previous Versions
			B.1. Changes from RFC 2068
			Transfer-coding and message lengths all interact in ways that
			required fixing exactly when chunked encoding is used (to allow for
			transfer encoding that may not be self delimiting); it was important
			to straighten out exactly how message lengths are computed.
			(Section 5.2, see also [Part1], [Part3] and [Part6])
	There are situations where a server (especially a proxy) does not		There are situations where a server (especially a proxy) does not
	know the full length of a response but is capable of serving a		know the full length of a response but is capable of serving a
	byterange request. We therefore need a mechanism to allow byteranges		byterange request. We therefore need a mechanism to allow byteranges
	with a content-range not indicating the full length of the message.		with a content-range not indicating the full length of the message.
	(Section 5.2)		(Section 5.2)
	Range request responses would become very verbose if all meta-data		Range request responses would become very verbose if all meta-data
	were always returned; by allowing the server to only send needed		were always returned; by allowing the server to only send needed
	headers in a 206 response, this problem can be avoided.		headers in a 206 response, this problem can be avoided. (Section 3.1
			and 5.3)
	Fix problem with unsatisfiable range requests; there are two cases:		Fix problem with unsatisfiable range requests; there are two cases:
	syntactic problems, and range doesn't exist in the document. The 416		syntactic problems, and range doesn't exist in the document. The 416
	status code was needed to resolve this ambiguity needed to indicate		status code was needed to resolve this ambiguity needed to indicate
	an error for a byte range request that falls outside of the actual		an error for a byte range request that falls outside of the actual
	contents of a document. (Section 3.2, 5.2)		contents of a document. (Section 3.2, 5.2)
			B.2. Changes from RFC 2616
			Clarify that it is not ok to use a weak cache validator in a 206
			response. (Section 3.1)
			Appendix C. Change Log (to be removed by RFC Editor before publication)
			C.1. Since RFC2616
			Extracted relevant partitions from [RFC2616].
			C.2. Since draft-ietf-httpbis-p5-range-00
			Closed issues:
			o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/18>: "Cache
			validators in 206 responses"
			(<http://purl.org/NET/http-errata#ifrange206>)
			o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative
			and Informative references"
			o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative
			up-to-date references"
	Index		Index
	2		2
	206 Partial Content (status code) 4		206 Partial Content (status code) 5
	4		4
	416 Requested Range Not Satisfiable (status code) 5		416 Requested Range Not Satisfiable (status code) 6
	A		A
	Accept-Ranges header 6		Accept-Ranges header 7
	C		C
	Content-Range header 7		Content-Range header 7
	G		G
	Grammar		Grammar
	Accept-Ranges 6		Accept-Ranges 7
	acceptable-ranges 6		acceptable-ranges 7
	byte-content-range-spec 7		byte-content-range-spec 7
	byte-range-resp-spec 7		byte-range-resp-spec 7
	byte-range-set 10		byte-range-set 10
	byte-range-spec 10		byte-range-spec 10
	byte-ranges-specifier 10		byte-ranges-specifier 10
	bytes-unit 4		bytes-unit 5
	Content-Range 7		Content-Range 7
	content-range-spec 7		content-range-spec 7
	first-byte-pos 10		first-byte-pos 10
	If-Range 9		If-Range 10
	instance-length 7		instance-length 7
	last-byte-pos 10		last-byte-pos 10
	other-range-unit 4		other-range-unit 5
	Range 11		Range 12
	range-unit 4		range-unit 5
	ranges-specifier 10		ranges-specifier 10
	suffix-byte-range-spec 10		suffix-byte-range-spec 11
	suffix-length 10		suffix-length 11
	H		H
	Headers		Headers
	Accept-Ranges 6		Accept-Ranges 7
	Content-Range 7		Content-Range 7
	If-Range 9		If-Range 9
	Range 9		Range 10
	I		I
	If-Range header 9		If-Range header 9
	M		M
	Media Type		Media Type
	multipart/byteranges 13		multipart/byteranges 14
	multipart/x-byteranges 14		multipart/x-byteranges 15
	multipart/byteranges Media Type 13		multipart/byteranges Media Type 14
	multipart/x-byteranges Media Type 14		multipart/x-byteranges Media Type 15
	R		R
	Range header 9		Range header 10
	S		S
	Status Codes		Status Codes
	206 Partial Content 4		206 Partial Content 5
	416 Requested Range Not Satisfiable 5		416 Requested Range Not Satisfiable 6
	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
	skipping to change at page 18, line 5		skipping to change at page 19, line 31
	World Wide Web Consortium		World Wide Web Consortium
	MIT Computer Science and Artificial Intelligence Laboratory		MIT Computer Science and Artificial Intelligence Laboratory
	The Stata Center, Building 32		The Stata Center, Building 32
	32 Vassar Street		32 Vassar Street
	Cambridge, MA 02139		Cambridge, MA 02139
	USA		USA
	Email: timbl@w3.org		Email: timbl@w3.org
	URI: http://www.w3.org/People/Berners-Lee/		URI: http://www.w3.org/People/Berners-Lee/
			Yves Lafon (editor)
			World Wide Web Consortium
			W3C / ERCIM
			2004, rte des Lucioles
			Sophia-Antipolis, AM 06902
			France
			Email: ylafon@w3.org
			URI: http://www.raubacapeu.net/people/yves/
			Julian F. Reschke (editor)
			greenbytes GmbH
			Hafenweg 16
			Muenster, NW 48155
			Germany
			Phone: +49 251 2807760
			Fax: +49 251 2807761
			Email: julian.reschke@greenbytes.de
			URI: http://greenbytes.de/tech/webdav/
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
End of changes. 47 change blocks.
	101 lines changed or deleted		212 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/