draft-ietf-httpbis-p5-range-19.txt		draft-ietf-httpbis-p5-range-latest.txt
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis Working Group R. Fielding, Ed.
	Internet-Draft Adobe		Internet-Draft Adobe
	Obsoletes: 2616 (if approved) Y. Lafon, Ed.		Obsoletes: 2616 (if approved) Y. Lafon, Ed.
	Intended status: Standards Track W3C		Intended status: Standards Track W3C
	Expires: September 13, 2012 J. Reschke, Ed.		Expires: November 20, 2012 J. Reschke, Ed.
	greenbytes		greenbytes
	March 12, 2012		May 19, 2012
	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-19		draft-ietf-httpbis-p5-range-latest
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	protocol for distributed, collaborative, hypertext information		protocol for distributed, collaborative, hypertext information
	systems. 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.		"HTTP/1.1" and, taken together, obsoletes RFC 2616.
	Part 5 defines range-specific requests and the rules for constructing		Part 5 defines range requests and the rules for constructing and
	and combining responses to those requests.		combining responses to those requests.
	Editorial Note (To be removed by RFC Editor)		Editorial Note (To be removed by RFC Editor)
	Discussion of this draft 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), which is archived at		group mailing list (ietf-http-wg@w3.org), which is archived at
	<http://lists.w3.org/Archives/Public/ietf-http-wg/>.		<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
	The current issues list is at		The current issues list is at
	<http://tools.ietf.org/wg/httpbis/trac/report/3> and related		<http://tools.ietf.org/wg/httpbis/trac/report/3> and related
	documents (including fancy diffs) can be found at		documents (including fancy diffs) can be found at
	<http://tools.ietf.org/wg/httpbis/>.		<http://tools.ietf.org/wg/httpbis/>.
	The changes in this draft are summarized in Appendix D.20.		The changes in this draft are summarized in Appendix D.21.
	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 13, 2012.		This Internet-Draft will expire on November 20, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 47		skipping to change at page 3, line 47
	D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 24		D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 24
	D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 24		D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 24
	D.13. Since draft-ietf-httpbis-p5-range-11 . . . . . . . . . . . 24		D.13. Since draft-ietf-httpbis-p5-range-11 . . . . . . . . . . . 24
	D.14. Since draft-ietf-httpbis-p5-range-12 . . . . . . . . . . . 25		D.14. Since draft-ietf-httpbis-p5-range-12 . . . . . . . . . . . 25
	D.15. Since draft-ietf-httpbis-p5-range-13 . . . . . . . . . . . 25		D.15. Since draft-ietf-httpbis-p5-range-13 . . . . . . . . . . . 25
	D.16. Since draft-ietf-httpbis-p5-range-14 . . . . . . . . . . . 25		D.16. Since draft-ietf-httpbis-p5-range-14 . . . . . . . . . . . 25
	D.17. Since draft-ietf-httpbis-p5-range-15 . . . . . . . . . . . 25		D.17. Since draft-ietf-httpbis-p5-range-15 . . . . . . . . . . . 25
	D.18. Since draft-ietf-httpbis-p5-range-16 . . . . . . . . . . . 25		D.18. Since draft-ietf-httpbis-p5-range-16 . . . . . . . . . . . 25
	D.19. Since draft-ietf-httpbis-p5-range-17 . . . . . . . . . . . 25		D.19. Since draft-ietf-httpbis-p5-range-17 . . . . . . . . . . . 25
	D.20. Since draft-ietf-httpbis-p5-range-18 . . . . . . . . . . . 25		D.20. Since draft-ietf-httpbis-p5-range-18 . . . . . . . . . . . 25
			D.21. Since draft-ietf-httpbis-p5-range-19 . . . . . . . . . . . 26
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	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 client has		of cancelled requests or dropped connections. When a client 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
	skipping to change at page 5, line 34		skipping to change at page 5, line 34
	Note that all rules derived from token are to be compared case-		Note that all rules derived from token are to be compared case-
	insensitively, like range-unit and acceptable-ranges.		insensitively, like range-unit and acceptable-ranges.
	1.2.1. Core Rules		1.2.1. Core Rules
	The core rules below are defined in [Part1] and [Part2]:		The core rules below are defined in [Part1] and [Part2]:
	OWS = <OWS, defined in [Part1], Section 3.2.1>		OWS = <OWS, defined in [Part1], Section 3.2.1>
	token = <token, defined in [Part1], Section 3.2.4>		token = <token, defined in [Part1], Section 3.2.4>
	HTTP-date = <HTTP-date, defined in [Part2], Section 8>		HTTP-date = <HTTP-date, defined in [Part2], Section 5.1>
	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:
	entity-tag = <entity-tag, defined in [Part4], Section 2.3>		entity-tag = <entity-tag, defined in [Part4], Section 2.3>
	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
	skipping to change at page 7, line 7		skipping to change at page 7, line 7
	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 Cache-Control, ETag, Expires, Content-Location, Last-Modified,		o Cache-Control, ETag, Expires, Content-Location and/or Vary, if the
	and/or Vary, if the header field would have been sent in a 200		header field would have been sent in a 200 response to the same
	response to the same request		request
	If the 206 response is the result of an If-Range request, the		If a 206 is sent in response to a request with an If-Range header
	response SHOULD NOT include other representation header fields.		field, it SHOULD NOT include other representation header fields.
	Otherwise, the response MUST include all of the representation header		Otherwise, the response MUST include all of the representation header
	fields that would have been returned with a 200 (OK) response to the		fields that would have been returned with a 200 (OK) response to the
	same request.		same request.
	Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to		Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
	determine freshness for 206 responses.		determine freshness for 206 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
	skipping to change at page 8, line 22		skipping to change at page 8, line 22
	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.		in Appendix A.
	A server MAY combine requested ranges when those ranges are		A server MAY combine requested ranges when those ranges are
	overlapping (see Section 7).		overlapping (see Section 7.1).
	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 ranges in one request, the server		When a client asks for multiple ranges in one request, the server
	SHOULD return them in the order that they appeared in the request.		SHOULD return them in the order that they appeared in the request.
	4.2. Combining Ranges		4.2. Combining Ranges
	A response might transfer only a subrange of a representation if the		A response might transfer only a subrange of a representation if the
	connection closed prematurely or if the request used one or more		connection closed prematurely or if the request used one or more
	Range specifications. After several such transfers, a client might		Range specifications. After several such transfers, a client might
	have received several ranges of the same representation. These		have received several ranges of the same representation. These
	ranges can only be safely combined if they all have in common the		ranges can only be safely combined if they all have in common the
	same strong validator, where "strong validator" is defined to be		same strong validator, where "strong validator" is defined to be
	skipping to change at page 16, line 48		skipping to change at page 16, line 48
	8. Acknowledgments		8. Acknowledgments
	See Section 9 of [Part1].		See Section 9 of [Part1].
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[Part1] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,		[Part1] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
	"HTTP/1.1, part 1: URIs, Connections, and Message		"HTTP/1.1, part 1: URIs, Connections, and Message
	Parsing", draft-ietf-httpbis-p1-messaging-19 (work in		Parsing", draft-ietf-httpbis-p1-messaging-latest (work in
	progress), March 2012.		progress), May 2012.
	[Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,		[Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
	"HTTP/1.1, part 2: Message Semantics",		"HTTP/1.1, part 2: Message Semantics",
	draft-ietf-httpbis-p2-semantics-19 (work in progress),		draft-ietf-httpbis-p2-semantics-latest (work in progress),
	March 2012.		May 2012.
	[Part4] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,		[Part4] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
	"HTTP/1.1, part 4: Conditional Requests",		"HTTP/1.1, part 4: Conditional Requests",
	draft-ietf-httpbis-p4-conditional-19 (work in progress),		draft-ietf-httpbis-p4-conditional-latest (work in
	March 2012.		progress), May 2012.
	[Part6] Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., Ed.,		[Part6] Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",		and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
	draft-ietf-httpbis-p6-cache-19 (work in progress),		draft-ietf-httpbis-p6-cache-latest (work in progress),
	March 2012.		May 2012.
	[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 20, line 5		skipping to change at page 20, line 5
	Notes:		Notes:
	1. Additional CRLFs MAY precede the first boundary string in the		1. Additional CRLFs MAY precede the first boundary string in the
	body.		body.
	2. Although [RFC2046] permits the boundary string to be quoted, some		2. Although [RFC2046] permits the boundary string to be quoted, some
	existing implementations handle a quoted boundary string		existing implementations handle a quoted boundary string
	incorrectly.		incorrectly.
	3. A number of browsers and servers were coded to an early draft of		3. A number of clients 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 2616		Appendix B. Changes from RFC 2616
	Clarify that it is not ok to use a weak validator in a 206 response.		Clarify that it is not ok to use a weak validator in a 206 response.
	(Section 3.1)		(Section 3.1)
	Change ABNF productions for header fields to only define the field		Change ABNF productions for header fields to only define the field
	skipping to change at page 21, line 11		skipping to change at page 21, line 11
	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 = acceptable-ranges
	Content-Range = byte-content-range-spec / other-content-range-spec		Content-Range = byte-content-range-spec / other-content-range-spec
	HTTP-date = <HTTP-date, defined in [Part2], Section 8>		HTTP-date = <HTTP-date, defined in [Part2], Section 6.1>
	If-Range = entity-tag / HTTP-date		If-Range = entity-tag / HTTP-date
	OWS = <OWS, defined in [Part1], Section 3.2.1>		OWS = <OWS, defined in [Part1], Section 3.2.1>
	Range = byte-ranges-specifier / other-ranges-specifier		Range = 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"
	skipping to change at page 26, line 6		skipping to change at page 26, line 6
	None.		None.
	D.20. Since draft-ietf-httpbis-p5-range-18		D.20. Since draft-ietf-httpbis-p5-range-18
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/311>: "Add		o <http://tools.ietf.org/wg/httpbis/trac/ticket/311>: "Add
	limitations to Range to reduce its use as a denial-of-service		limitations to Range to reduce its use as a denial-of-service
	tool"		tool"
			D.21. Since draft-ietf-httpbis-p5-range-19
			None yet.
	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 9		Accept-Ranges header field 9
End of changes. 19 change blocks.
	25 lines changed or deleted		30 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/