draft-ietf-httpbis-p5-range-18.txt   draft-ietf-httpbis-p5-range-19.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) Y. Lafon, Ed.
Intended status: Standards Track Alcatel-Lucent Intended status: Standards Track W3C
Expires: July 7, 2012 J. Mogul Expires: September 13, 2012 J. Reschke, Ed.
HP
H. Frystyk
Microsoft
L. Masinter
Adobe
P. Leach
Microsoft
T. Berners-Lee
W3C/MIT
Y. Lafon, Ed.
W3C
J. Reschke, Ed.
greenbytes greenbytes
January 4, 2012 March 12, 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-18 draft-ietf-httpbis-p5-range-19
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.
skipping to change at page 1, line 49 skipping to change at page 1, line 37
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.19. The changes in this draft are summarized in Appendix D.20.
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 July 7, 2012. This Internet-Draft will expire on September 13, 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 2, line 51 skipping to change at page 2, line 39
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conformance and Error Handling . . . . . . . . . . . . . . 5 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2. ABNF Rules defined in other Parts of the 1.2.2. ABNF Rules defined in other Parts of the
Specification . . . . . . . . . . . . . . . . . . . . 6 Specification . . . . . . . . . . . . . . . . . . . . 5
2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 7 2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 6
3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 6
3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 7 3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 6
3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 8 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 7
4. Combining Ranges . . . . . . . . . . . . . . . . . . . . . . . 8 4. Responses to a Range Request . . . . . . . . . . . . . . . . . 7
4.1. Response to a Single and Multiple Ranges Request . . . . . 7
4.2. Combining Ranges . . . . . . . . . . . . . . . . . . . . . 8
5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 9 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 9
5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 10
5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 13 5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 12
5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 15 5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6.1. Status Code Registration . . . . . . . . . . . . . . . . . 16 6.1. Status Code Registration . . . . . . . . . . . . . . . . . 15
6.2. Header Field Registration . . . . . . . . . . . . . . . . 16 6.2. Header Field Registration . . . . . . . . . . . . . . . . 15
6.3. Range Specifier Registration . . . . . . . . . . . . . . . 16 6.3. Range Specifier Registration . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7.1. Overlapping Ranges . . . . . . . . . . . . . . . . . . . . 17 7.1. Overlapping Ranges . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Internet Media Type multipart/byteranges . . . . . . 18 Appendix A. Internet Media Type multipart/byteranges . . . . . . 17
Appendix B. Compatibility with Previous Versions . . . . . . . . 21 Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 20
B.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 21 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 21
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 22
Appendix D. Change Log (to be removed by RFC Editor before Appendix D. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 23 publication) . . . . . . . . . . . . . . . . . . . . 22
D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 23 D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 22
D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 23 D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 22
D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 23 D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 22
D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 23 D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 22
D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 24 D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 23
D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 24 D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 23
D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 24 D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 23
D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 24 D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 23
D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 25 D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 24
D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 25 D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 24
D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 25 D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 24
D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 25 D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 24
D.13. Since draft-ietf-httpbis-p5-range-11 . . . . . . . . . . . 25 D.13. Since draft-ietf-httpbis-p5-range-11 . . . . . . . . . . . 24
D.14. Since draft-ietf-httpbis-p5-range-12 . . . . . . . . . . . 26 D.14. Since draft-ietf-httpbis-p5-range-12 . . . . . . . . . . . 25
D.15. Since draft-ietf-httpbis-p5-range-13 . . . . . . . . . . . 26 D.15. Since draft-ietf-httpbis-p5-range-13 . . . . . . . . . . . 25
D.16. Since draft-ietf-httpbis-p5-range-14 . . . . . . . . . . . 26 D.16. Since draft-ietf-httpbis-p5-range-14 . . . . . . . . . . . 25
D.17. Since draft-ietf-httpbis-p5-range-15 . . . . . . . . . . . 26 D.17. Since draft-ietf-httpbis-p5-range-15 . . . . . . . . . . . 25
D.18. Since draft-ietf-httpbis-p5-range-16 . . . . . . . . . . . 26 D.18. Since draft-ietf-httpbis-p5-range-16 . . . . . . . . . . . 25
D.19. Since draft-ietf-httpbis-p5-range-17 . . . . . . . . . . . 26 D.19. Since draft-ietf-httpbis-p5-range-17 . . . . . . . . . . . 25
D.20. Since draft-ietf-httpbis-p5-range-18 . . . . . . . . . . . 25
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 6, line 13 skipping to change at page 5, line 13
define specific error handling mechanisms, except in cases where it define specific error handling mechanisms, except in cases where it
has direct impact on security. This is because different uses of the has direct impact on security. This is because different uses of the
protocol require different error handling strategies; for example, a protocol require different error handling strategies; for example, a
Web browser may wish to transparently recover from a response where Web browser may wish to transparently recover from a response where
the Location header field doesn't parse according to the ABNF, the Location header field doesn't parse according to the ABNF,
whereby in a systems control protocol using HTTP, this type of error whereby in a systems control protocol using HTTP, this type of error
recovery could lead to dangerous consequences. recovery could lead to dangerous consequences.
1.2. Syntax Notation 1.2. Syntax Notation
This specification uses the ABNF syntax defined in Section 1.2 of This specification uses the Augmented Backus-Naur Form (ABNF)
[Part1] (which extends the syntax defined in [RFC5234] with a list notation of [RFC5234] with the list rule extension defined in Section
rule). Appendix C shows the collected ABNF, with the list rule 1.2 of [Part1]. Appendix C shows the collected ABNF with the list
expanded. rule expanded.
The following core rules are included by reference, as defined in The following core rules are included by reference, as defined in
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
sequence of data), SP (space), and VCHAR (any visible US-ASCII sequence of data), SP (space), and VCHAR (any visible US-ASCII
character). character).
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 1.2.2> OWS = <OWS, defined in [Part1], Section 3.2.1>
token = <token, defined in [Part1], Section 3.2.3> 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 8>
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
skipping to change at page 7, line 29 skipping to change at page 6, line 29
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
Values to be added to this name space are subject to IETF review Values to be added to this name space require IETF Review (see
([RFC5226], Section 4.1). [RFC5226], Section 4.1).
The registry itself is maintained at The registry itself is maintained at
<http://www.iana.org/assignments/http-range-specifiers>. <http://www.iana.org/assignments/http-range-specifiers>.
3. Status Code Definitions 3. Status Code Definitions
3.1. 206 Partial Content 3.1. 206 Partial Content
The server has fulfilled the partial GET request for the resource. The server has fulfilled the partial GET request for the resource.
The request MUST have included a Range header field (Section 5.4) The request MUST have included a Range header field (Section 5.4)
indicating the desired range, and MAY have included an If-Range indicating the desired range, and MAY have included an If-Range
header field (Section 5.3) to make the request conditional. header field (Section 5.3) to make the request conditional.
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 Cache-Control, ETag, Expires, Content-Location, Last-Modified, o Cache-Control, ETag, Expires, Content-Location, Last-Modified,
and/or Vary, if the header field would have been sent in a 200 and/or Vary, if the header field would have been sent in a 200
response to the same request response to the same request
If the 206 response is the result of an If-Range request, the If the 206 response is the result of an If-Range request, the
response SHOULD NOT include other representation header fields. response SHOULD NOT include other representation header fields.
Otherwise, the response MUST include all of the representation header Otherwise, the response MUST include all of the representation header
fields that would have been returned with a 200 (OK) response to the fields that would have been returned with a 200 (OK) response to the
same request. same request.
Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
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
included a Range header field (Section 5.4), and none of the ranges- included a Range header field (Section 5.4), and none of the ranges-
specifier values in this field overlap the current extent of the specifier values in this field overlap the current extent of the
selected resource, and the request did not include an If-Range header selected resource, and the request did not include an If-Range header
field (Section 5.3). (For byte-ranges, this means that the first- field (Section 5.3). (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.)
When this status code is returned for a byte-range request, the When this status code is returned for a byte-range request, the
response SHOULD include a Content-Range header field specifying the response SHOULD include a Content-Range header field specifying the
current length of the representation (see Section 5.2). This current length of the representation (see Section 5.2). This
response MUST NOT use the multipart/byteranges content-type. response MUST NOT use the multipart/byteranges content-type. For
example,
4. Combining Ranges HTTP/1.1 416 Requested Range Not Satisfiable
Date: Mon, 20 Jan 2012 15:41:54 GMT
Content-Range: bytes */47022
Content-Type: image/gif
Note: Clients cannot depend on servers to send a 416 (Requested
range not satisfiable) response instead of a 200 (OK) response for
an unsatisfiable Range header field, since not all servers
implement this header field.
4. Responses to a Range Request
4.1. Response to a Single and Multiple Ranges Request
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
for a set of ranges that overlap without any holes), this content is
transmitted with a Content-Range header field, and a Content-Length
header field showing the number of bytes actually transferred. For
example,
HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif
When an HTTP message includes the content of multiple ranges (for
example, a response to a request for multiple non-overlapping
ranges), these are transmitted as a multipart message. The multipart
media type used for this purpose is "multipart/byteranges" as defined
in Appendix A.
A server MAY combine requested ranges when those ranges are
overlapping (see Section 7).
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
multiple ranges, whose result is a single range, MAY be sent as a
multipart/byteranges media type with one part. A client that cannot
decode a multipart/byteranges message MUST NOT ask for multiple
ranges in a single request.
When a client requests multiple ranges in one request, the server
SHOULD return them in the order that they appeared in the request.
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
either an entity-tag that is not marked as weak (Section 2.3 of either an entity-tag that is not marked as weak (Section 2.3 of
[Part4]) or, if no entity-tag is provided, a Last-Modified value that [Part4]) or, if no entity-tag is provided, a Last-Modified value that
is strong in the sense defined by Section 2.2.2 of [Part4]. is strong in the sense defined by Section 2.2.2 of [Part4].
skipping to change at page 9, line 19 skipping to change at page 9, line 21
If the new response is a 206 (Partial Content) response and at least If the new response is a 206 (Partial Content) response and at least
one of the matching stored responses is a 200 (OK), then the combined one of the matching stored responses is a 200 (OK), then the combined
response header fields consist of the most recent 200 response's response header fields consist of the most recent 200 response's
header fields. If all of the matching stored responses are 206 header fields. If all of the matching stored responses are 206
responses, then the stored response with the most header fields is responses, then the stored response with the most header fields is
used as the source of header fields for the combined response, except used as the source of header fields for the combined response, except
that the client MUST use other header fields provided in the new that the client MUST use other header fields provided in the new
response, aside from Content-Range, to replace all instances of the response, aside from Content-Range, to replace all instances of the
corresponding header fields in the stored response. corresponding header fields in the stored response.
The combined response message-body consists of the union of partial The combined response message body consists of the union of partial
content ranges in the new response and each of the selected content ranges in the new response and each of the selected
responses. If the union consists of the entire range of the responses. If the union consists of the entire range of the
representation, then the combined response MUST be recorded as a representation, then the combined response MUST be recorded as a
complete 200 (OK) response with a Content-Length header field that complete 200 (OK) response with a Content-Length header field that
reflects the complete length. Otherwise, the combined response(s) reflects the complete length. Otherwise, the combined response(s)
MUST include a Content-Range header field describing the included MUST include a Content-Range header field describing the included
range(s) and be recorded as incomplete. If the union consists of a range(s) and be recorded as incomplete. If the union consists of a
discontinuous range of the representation, then the client MAY store discontinuous range of the representation, then the client MAY store
it as either a multipart range response or as multiple 206 responses it as either a multipart range response or as multiple 206 responses
with one continuous range each. with one continuous range each.
skipping to change at page 11, line 33 skipping to change at page 11, line 36
bytes 500-999/1234 bytes 500-999/1234
o All except for the first 500 bytes: o All except for the first 500 bytes:
bytes 500-1233/1234 bytes 500-1233/1234
o The last 500 bytes: o The last 500 bytes:
bytes 734-1233/1234 bytes 734-1233/1234
When an HTTP message includes the content of a single range (for If the server ignores a byte-range-spec (for example if it is
example, a response to a request for a single range, or to a request syntactically invalid, or if it may be seen as a denial-of-service
for a set of ranges that overlap without any holes), this content is attack), the server SHOULD treat the request as if the invalid Range
transmitted with a Content-Range header field, and a Content-Length
header field showing the number of bytes actually transferred. For
example,
HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif
When an HTTP message includes the content of multiple ranges (for
example, a response to a request for multiple non-overlapping
ranges), these are transmitted as a multipart message. The multipart
media type used for this purpose is "multipart/byteranges" as defined
in Appendix A.
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
multiple ranges, whose result is a single range, MAY be sent as a
multipart/byteranges media type with one part. A client that cannot
decode a multipart/byteranges message MUST NOT ask for multiple
ranges in a single request.
When a client requests multiple ranges in one request, the server
SHOULD return them in the order that they appeared in the request.
If the server ignores a byte-range-spec because it is syntactically
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 representation). response containing the full representation).
If the server receives a request (other than one including an If-
Range header field) with an unsatisfiable Range 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 resource), it SHOULD
return a response code of 416 (Requested range not satisfiable)
(Section 3.2).
Note: Clients cannot depend on servers to send a 416 (Requested
range not satisfiable) response instead of a 200 (OK) response for
an unsatisfiable Range header field, since not all servers
implement this header field.
5.3. If-Range 5.3. If-Range
If a client has a partial copy of a representation and wishes to have If a client has a partial copy of a representation and wishes to have
an up-to-date copy of the entire representation, it could use the an up-to-date copy of the entire representation, it could use the
Range header field with a conditional GET (using either or both of Range header field with a conditional GET (using either or both of
If-Unmodified-Since and If-Match.) However, if the condition fails If-Unmodified-Since and If-Match.) However, if the condition fails
because the representation has been modified, the client would then because the representation has been modified, the client would then
have to make a second request to obtain the entire current have to make a second request to obtain the entire current
representation. representation.
skipping to change at page 13, line 37 skipping to change at page 12, line 47
5.4. Range 5.4. Range
5.4.1. Byte Ranges 5.4.1. Byte Ranges
Since all HTTP representations are transferred as sequences of bytes, Since all HTTP representations are transferred as sequences of bytes,
the concept of a byte range is meaningful for any HTTP the concept of a byte range is meaningful for any HTTP
representation. (However, not all clients and servers need to representation. (However, not all clients and servers need to
support byte-range operations.) support byte-range operations.)
Byte range specifications in HTTP apply to the sequence of bytes in Byte range specifications in HTTP apply to the sequence of bytes in
the representation body (not necessarily the same as the message- the representation body (not necessarily the same as the message
body). body).
A byte range operation MAY specify a single range of bytes, or a set A byte range operation MAY specify a single range of bytes, or a set
of ranges within a single representation. of ranges within a single representation.
byte-ranges-specifier = bytes-unit "=" byte-range-set byte-ranges-specifier = bytes-unit "=" byte-range-set
byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec ) byte-range-set = 1#( 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 ]
first-byte-pos = 1*DIGIT first-byte-pos = 1*DIGIT
last-byte-pos = 1*DIGIT last-byte-pos = 1*DIGIT
skipping to change at page 17, line 31 skipping to change at page 16, line 40
some suggestions for reducing security risks. some suggestions for reducing security risks.
7.1. Overlapping Ranges 7.1. Overlapping Ranges
Range requests containing overlapping ranges may lead to the Range requests containing overlapping ranges may lead to the
situation where a server is sending far more data than the size of situation where a server is sending far more data than the size of
the complete resource representation. the complete resource representation.
8. Acknowledgments 8. Acknowledgments
See Section 11 of [Part1]. See Section 9 of [Part1].
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., Lafon, Y., Ed., and J. Reschke, Ed.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., "HTTP/1.1, part 1: URIs, Connections, and Message
and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, Parsing", draft-ietf-httpbis-p1-messaging-19 (work in
and Message Parsing", draft-ietf-httpbis-p1-messaging-18 progress), March 2012.
(work in progress), January 2012.
[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., "HTTP/1.1, part 2: Message Semantics",
and J. Reschke, Ed., "HTTP/1.1, part 2: Message draft-ietf-httpbis-p2-semantics-19 (work in progress),
Semantics", draft-ietf-httpbis-p2-semantics-18 (work in March 2012.
progress), January 2012.
[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part4] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., "HTTP/1.1, part 4: Conditional Requests",
and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional draft-ietf-httpbis-p4-conditional-19 (work in progress),
Requests", draft-ietf-httpbis-p4-conditional-18 (work in March 2012.
progress), January 2012.
[Part6] Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
draft-ietf-httpbis-p6-cache-19 (work in progress),
March 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 18, line 38 skipping to change at page 17, line 49
Registration Procedures", BCP 13, RFC 4288, December 2005. Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
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 Note: Despite the name "multipart/byteranges" is not limited to
the byte ranges only. 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
skipping to change at page 21, line 10 skipping to change at page 20, line 10
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 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. Compatibility with Previous Versions Appendix B. Changes from RFC 2616
B.1. 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
value. (Section 5) 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 = 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 8>
If-Range = entity-tag / HTTP-date If-Range = entity-tag / HTTP-date
OWS = <OWS, defined in [Part1], Section 1.2.2> 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"
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 ) / (
skipping to change at page 22, line 51 skipping to change at page 21, line 51
other-range-resp-spec = *CHAR other-range-resp-spec = *CHAR
other-range-set = 1*CHAR other-range-set = 1*CHAR
other-range-unit = token other-range-unit = token
other-ranges-specifier = other-range-unit "=" other-range-set 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 3.2.3> token = <token, defined in [Part1], Section 3.2.4>
ABNF diagnostics: ABNF diagnostics:
; Accept-Ranges defined but not used ; Accept-Ranges defined but not used
; Content-Range defined but not used ; Content-Range defined but not used
; If-Range defined but not used ; If-Range defined but not used
; Range defined but not used ; Range defined but not used
Appendix D. Change Log (to be removed by RFC Editor before publication) Appendix D. Change Log (to be removed by RFC Editor before publication)
D.1. Since RFC 2616 D.1. Since RFC 2616
skipping to change at page 26, line 47 skipping to change at page 25, line 47
o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/301>: "Content- o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/301>: "Content-
Range on responses other than 206" Range on responses other than 206"
o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/319>: "case o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/319>: "case
sensitivity of ranges in p5" sensitivity of ranges in p5"
D.19. Since draft-ietf-httpbis-p5-range-17 D.19. Since draft-ietf-httpbis-p5-range-17
None. None.
D.20. Since draft-ietf-httpbis-p5-range-18
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/311>: "Add
limitations to Range to reduce its use as a denial-of-service
tool"
Index Index
2 2
206 Partial Content (status code) 7 206 Partial Content (status code) 6
4 4
416 Requested Range Not Satisfiable (status code) 8 416 Requested Range Not Satisfiable (status code) 7
A A
Accept-Ranges header field 9 Accept-Ranges header field 9
C C
Content-Range header field 10 Content-Range header field 10
G G
Grammar Grammar
Accept-Ranges 9 Accept-Ranges 9
acceptable-ranges 9 acceptable-ranges 9
byte-content-range-spec 10 byte-content-range-spec 10
byte-range-resp-spec 10 byte-range-resp-spec 10
byte-range-set 13 byte-range-set 13
byte-range-spec 13 byte-range-spec 13
byte-ranges-specifier 13 byte-ranges-specifier 13
bytes-unit 6 bytes-unit 5
Content-Range 10 Content-Range 10
first-byte-pos 13 first-byte-pos 13
If-Range 12 If-Range 12
instance-length 10 instance-length 10
last-byte-pos 13 last-byte-pos 13
other-range-unit 6 other-range-unit 5
Range 15 Range 14
range-unit 6 range-unit 5
ranges-specifier 13 ranges-specifier 13
suffix-byte-range-spec 14 suffix-byte-range-spec 13
suffix-length 14 suffix-length 13
H H
Header Fields Header Fields
Accept-Ranges 9 Accept-Ranges 9
Content-Range 10 Content-Range 10
If-Range 12 If-Range 11
Range 13 Range 12
I I
If-Range header field 12 If-Range header field 11
M M
Media Type Media Type
multipart/byteranges 18 multipart/byteranges 17
multipart/x-byteranges 21 multipart/x-byteranges 20
multipart/byteranges Media Type 18 multipart/byteranges Media Type 17
multipart/x-byteranges Media Type 21 multipart/x-byteranges Media Type 20
R R
Range header field 13 Range header field 12
S S
Status Codes Status Codes
206 Partial Content 7 206 Partial Content 6
416 Requested Range Not Satisfiable 8 416 Requested Range Not Satisfiable 7
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Adobe Systems Incorporated Adobe Systems Incorporated
345 Park Ave 345 Park Ave
San Jose, CA 95110 San Jose, CA 95110
USA USA
EMail: fielding@gbiv.com EMail: fielding@gbiv.com
URI: http://roy.gbiv.com/ URI: http://roy.gbiv.com/
Jim Gettys
Alcatel-Lucent Bell Labs
21 Oak Knoll Road
Carlisle, MA 01741
USA
EMail: jg@freedesktop.org
URI: http://gettys.wordpress.com/
Jeffrey C. Mogul
Hewlett-Packard Company
HP Labs, Large Scale Systems Group
1501 Page Mill Road, MS 1177
Palo Alto, CA 94304
USA
EMail: JeffMogul@acm.org
Henrik Frystyk Nielsen
Microsoft Corporation
1 Microsoft Way
Redmond, WA 98052
USA
EMail: henrikn@microsoft.com
Larry Masinter
Adobe Systems Incorporated
345 Park Ave
San Jose, CA 95110
USA
EMail: LMM@acm.org
URI: http://larry.masinter.net/
Paul J. Leach
Microsoft Corporation
1 Microsoft Way
Redmond, WA 98052
EMail: paulle@microsoft.com
Tim Berners-Lee
World Wide Web Consortium
MIT Computer Science and Artificial Intelligence Laboratory
The Stata Center, Building 32
32 Vassar Street
Cambridge, MA 02139
USA
EMail: timbl@w3.org
URI: http://www.w3.org/People/Berners-Lee/
Yves Lafon (editor) Yves Lafon (editor)
World Wide Web Consortium World Wide Web Consortium
W3C / ERCIM W3C / ERCIM
2004, rte des Lucioles 2004, rte des Lucioles
Sophia-Antipolis, AM 06902 Sophia-Antipolis, AM 06902
France France
EMail: ylafon@w3.org EMail: ylafon@w3.org
URI: http://www.raubacapeu.net/people/yves/ URI: http://www.raubacapeu.net/people/yves/
Julian F. Reschke (editor) Julian F. Reschke (editor)
 End of changes. 41 change blocks. 
216 lines changed or deleted 172 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/