draft-ietf-httpbis-p5-range-15.txt   draft-ietf-httpbis-p5-range-16.txt 
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: 2616 (if approved) J. Gettys Obsoletes: 2616 (if approved) J. Gettys
Intended status: Standards Track Alcatel-Lucent Intended status: Standards Track Alcatel-Lucent
Expires: January 12, 2012 J. Mogul Expires: February 25, 2012 J. Mogul
HP HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Adobe
P. Leach P. Leach
Microsoft Microsoft
T. Berners-Lee T. Berners-Lee
W3C/MIT W3C/MIT
Y. Lafon, Ed. Y. Lafon, Ed.
W3C W3C
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
July 11, 2011 August 24, 2011
HTTP/1.1, part 5: Range Requests and Partial Responses HTTP/1.1, part 5: Range Requests and Partial Responses
draft-ietf-httpbis-p5-range-15 draft-ietf-httpbis-p5-range-16
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, 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. Part 5 defines "HTTP/1.1" and, taken together, obsoletes RFC 2616.
range-specific requests and the rules for constructing and combining
responses to those requests. Part 5 defines range-specific requests and the rules for constructing
and 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.16. The changes in this draft are summarized in Appendix D.17.
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 January 12, 2012. This Internet-Draft will expire on February 25, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 12 skipping to change at page 3, line 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . 6
2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 6 2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 6
3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7
3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 7 3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 7
3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 8 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 7
4. Combining Ranges . . . . . . . . . . . . . . . . . . . . . . . 8 4. Combining Ranges . . . . . . . . . . . . . . . . . . . . . . . 8
5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 8 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 9
5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 9
5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 12 5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 13
5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 14 5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6.1. Status Code Registration . . . . . . . . . . . . . . . . . 15 6.1. Status Code Registration . . . . . . . . . . . . . . . . . 15
6.2. Header Field Registration . . . . . . . . . . . . . . . . 15 6.2. Header Field Registration . . . . . . . . . . . . . . . . 16
6.3. Range Specifier Registration . . . . . . . . . . . . . . . 16 6.3. Range Specifier Registration . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Overlapping Ranges . . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Internet Media Type multipart/byteranges . . . . . . 17 Appendix A. Internet Media Type multipart/byteranges . . . . . . 18
Appendix B. Compatibility with Previous Versions . . . . . . . . 20 Appendix B. Compatibility with Previous Versions . . . . . . . . 20
B.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 20 B.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 20
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 20 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 21
Appendix D. Change Log (to be removed by RFC Editor before Appendix D. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 22 publication) . . . . . . . . . . . . . . . . . . . . 22
D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 22 D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 22
D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 22 D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 22
D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 22 D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 22
D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 22 D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 22
D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 23 D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 23
D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 23 D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 23
D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 23 D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 23
D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 23 D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 23
D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 24 D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 24
D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 24 D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 24
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
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
HTTP clients often encounter interrupted data transfers as a result HTTP clients often encounter interrupted data transfers as a result
of cancelled requests or dropped connections. When a cache has of cancelled requests or dropped connections. When a 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
a larger representation, such as a single page of a very large 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 document or only part of an image to be rendered by a device with
limited local storage. limited local storage.
This document defines HTTP/1.1 range requests, partial responses, and This document defines HTTP/1.1 range requests, partial responses, and
the multipart/byteranges media type. The protocol for range requests the multipart/byteranges media type. The protocol for range requests
skipping to change at page 6, line 13 skipping to change at page 6, line 13
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), VCHAR (any visible USASCII character), sequence of data), SP (space), VCHAR (any visible USASCII character),
and WSP (whitespace). and WSP (whitespace).
1.2.1. Core Rules 1.2.1. Core Rules
The core rules below are defined in Section 1.2.2 of [Part1]: The core rules below are defined in [Part1]:
token = <token, defined in [Part1], Section 1.2.2>
OWS = <OWS, defined in [Part1], Section 1.2.2> OWS = <OWS, defined in [Part1], Section 1.2.2>
token = <token, defined in [Part1], Section 3.2.3>
HTTP-date = <HTTP-date, defined in [Part1], Section 6.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:
HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> entity-tag = <entity-tag, defined in [Part4], Section 2.3>
entity-tag = <entity-tag, defined in [Part4], Section 2.2>
2. Range Units 2. Range Units
HTTP/1.1 allows a client to request that only part (a range) of the HTTP/1.1 allows a client to request that only part (a range) of the
representation be included within the response. HTTP/1.1 uses range representation be included within the response. HTTP/1.1 uses range
units in the Range (Section 5.4) and Content-Range (Section 5.2) units in the Range (Section 5.4) and Content-Range (Section 5.2)
header fields. A representation can be broken down into subranges header fields. A representation can be broken down into subranges
according to various structural units. according to various structural units.
range-unit = bytes-unit / other-range-unit range-unit = bytes-unit / other-range-unit
skipping to change at page 7, line 49 skipping to change at page 7, line 47
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.
A cache MUST NOT combine a 206 response with other previously cached
content if the ETag or Last-Modified header fields do not match
exactly, see Section 4.
A cache that does not support the Range and Content-Range header
fields MUST NOT cache 206 (Partial Content) responses. Furthermore,
if a response uses a range unit that is not understood by the cache,
then it MUST NOT be cached either.
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.
4. Combining Ranges 4. Combining Ranges
A response might transfer only a subrange of a representation, either A response might transfer only a subrange of a representation if the
because the request included one or more Range specifications, or connection closed prematurely or if the request used one or more
because a connection closed prematurely. After several such Range specifications. After several such transfers, a client might
transfers, a cache might have received several ranges of the same have received several ranges of the same representation. These
representation. ranges can only be safely combined if they all have in common the
same strong validator, where "strong validator" is defined to be
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
is strong in the sense defined by Section 2.2.2 of [Part4].
If a cache has a stored non-empty set of subranges for a When a client receives an incomplete 200 (OK) or 206 (Partial
representation, and an incoming response transfers another subrange, Content) response and already has one or more stored responses for
the cache MAY combine the new subrange with the existing set if both the same method and effective request URI, all of the stored
the following conditions are met: responses with the same strong validator MAY be combined with the
partial content in this new response. If none of the stored
responses contain the same strong validator, then this new response
corresponds to a new representation and MUST NOT be combined with the
existing stored responses.
o Both the incoming response and the cache entry have a cache If the new response is an incomplete 200 (OK) response, then the
validator. header fields of that new response are used for any combined response
and replace those of the matching stored responses.
o The two cache validators match using the strong comparison If the new response is a 206 (Partial Content) response and at least
function (see Section 2.2.2 of [Part4]). one of the matching stored responses is a 200 (OK), then the combined
response header fields consist of the most recent 200 response's
header fields. If all of the matching stored responses are 206
responses, then the stored response with the most header fields is
used as the source of header fields for the combined response, except
that the client MUST use other header fields provided in the new
response, aside from Content-Range, to replace all instances of the
corresponding header fields in the stored response.
If either requirement is not met, the cache MUST use only the most The combined response message-body consists of the union of partial
recent partial response (based on the Date values transmitted with content ranges in the new response and each of the selected
every response, and using the incoming response if these values are responses. If the union consists of the entire range of the
equal or missing), and MUST discard the other partial information. representation, then the combined response MUST be recorded as a
complete 200 (OK) response with a Content-Length header field that
reflects the complete length. Otherwise, the combined response(s)
MUST include a Content-Range header field describing the included
range(s) and be recorded as incomplete. If the union consists of a
discontinuous range of the representation, then the client MAY store
it as either a multipart range response or as multiple 206 responses
with one continuous range each.
5. Header Field Definitions 5. Header Field Definitions
This section defines the syntax and semantics of HTTP/1.1 header This section defines the syntax and semantics of HTTP/1.1 header
fields related to range requests and partial responses. fields related to range requests and partial responses.
5.1. Accept-Ranges 5.1. Accept-Ranges
The "Accept-Ranges" header field allows a resource to indicate its The "Accept-Ranges" header field allows a resource to indicate its
acceptance of range requests. acceptance of range requests.
skipping to change at page 9, line 36 skipping to change at page 10, line 5
to advise the client not to attempt a range request. to advise the client not to attempt a range request.
5.2. Content-Range 5.2. Content-Range
The "Content-Range" header field is sent with a partial The "Content-Range" header field is sent with a partial
representation to specify where in the full representation the representation to specify where in the full representation the
payload body is intended to be applied. payload body is intended to be applied.
Range units are defined in Section 2. Range units are defined in Section 2.
Content-Range = content-range-spec Content-Range = byte-content-range-spec
content-range-spec = byte-content-range-spec
/ other-content-range-spec / other-content-range-spec
byte-content-range-spec = bytes-unit SP byte-content-range-spec = bytes-unit SP
byte-range-resp-spec "/" byte-range-resp-spec "/"
( instance-length / "*" ) ( instance-length / "*" )
byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)
/ "*" / "*"
instance-length = 1*DIGIT instance-length = 1*DIGIT
other-content-range-spec = other-range-unit SP other-content-range-spec = other-range-unit SP
skipping to change at page 11, line 46 skipping to change at page 12, line 17
return a response code of 416 (Requested range not satisfiable) return a response code of 416 (Requested range not satisfiable)
(Section 3.2). (Section 3.2).
Note: Clients cannot depend on servers to send a 416 (Requested Note: Clients cannot depend on servers to send a 416 (Requested
range not satisfiable) response instead of a 200 (OK) response for range not satisfiable) response instead of a 200 (OK) response for
an unsatisfiable Range header field, since not all servers an unsatisfiable Range header field, since not all servers
implement this header field. implement this header field.
5.3. If-Range 5.3. If-Range
If a client has a partial copy of a representation in its cache, and If a client has a partial copy of a representation and wishes to have
wishes to have an up-to-date copy of the entire representation in its an up-to-date copy of the entire representation, it could use the
cache, it could use the Range header field with a conditional GET Range header field with a conditional GET (using either or both of
(using either or both of If-Unmodified-Since and If-Match.) However, If-Unmodified-Since and If-Match.) However, if the condition fails
if the condition fails because the representation has been modified, because the representation has been modified, the client would then
the client would then have to make a second request to obtain the have to make a second request to obtain the entire current
entire current representation. representation.
The "If-Range" header field allows a client to "short-circuit" the The "If-Range" header field allows a client to "short-circuit" the
second request. Informally, its meaning is "if the representation is second request. Informally, its meaning is "if the representation is
unchanged, send me the part(s) that I am missing; otherwise, send me unchanged, send me the part(s) that I am missing; otherwise, send me
the entire new representation". the entire new representation".
If-Range = entity-tag / HTTP-date If-Range = entity-tag / HTTP-date
Only a strong validator (Section 2.2.2 of [Part4]) is usable for Clients MUST NOT use an entity-tag marked as weak in an If-Range
range retrieval, since otherwise the client might end up with an field value and MUST NOT use a Last-Modified date in an If-Range
internally inconsistent representation. Clients MUST NOT use weak field value unless it has no entity-tag for the representation and
validators in range requests. A cache or origin server receiving a the Last-Modified date it does have for the representation is strong
conditional range request MUST use the strong comparison function to in the sense defined by Section 2.2.2 of [Part4].
evaluate the condition.
If the client has no entity-tag for a representation, but does have a A server that evaluates a conditional range request that is
Last-Modified date, it MAY use that date in an If-Range header field. applicable to one of its representations MUST evaluate the condition
(The server can distinguish between a valid HTTP-date and any form of as false if the entity-tag used as a validator is marked as weak or,
entity-tag by examining no more than two characters.) The If-Range when an HTTP-date is used as the validator, if the date value is not
header field SHOULD only be used together with a Range header field, strong in the sense defined by Section 2.2.2 of [Part4]. (A server
and MUST be ignored if the request does not include a Range header can distinguish between a valid HTTP-date and any form of entity-tag
field, or if the server does not support the sub-range operation. by examining the first two characters.)
If a client wishes to perform a sub-range retrieval on a value for The If-Range header field SHOULD only be sent by clients together
which it has only a Last-Modified time and no opaque validator, it with a Range header field. The If-Range header field MUST be ignored
MAY do this only if the Last-Modified time is strong in the sense if it is received in a request that does not include a Range header
described in Section 2.1.2 of [Part4]. field. The If-Range header field MUST be ignored by a server that
does not support the sub-range operation.
If the entity-tag given in the If-Range header field matches the If the validator given in the If-Range header field matches the
current cache validator for the representation, then the server current validator for the selected representation of the target
SHOULD provide the specified sub-range of the representation using a resource, then the server SHOULD send the specified sub-range of the
206 (Partial Content) response. If the cache validator does not representation using a 206 (Partial Content) response. If the
match, then the server SHOULD return the entire representation using validator does not match, then the server SHOULD send the entire
a 200 (OK) response. representation using a 200 (OK) response.
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.)
skipping to change at page 14, line 44 skipping to change at page 15, line 15
5.4.2. Range Retrieval Requests 5.4.2. Range Retrieval Requests
The "Range" header field defines the GET method (conditional or not) The "Range" header field defines the GET method (conditional or not)
to request one or more sub-ranges of the response representation to request one or more sub-ranges of the response representation
body, instead of the entire representation body. body, instead of the entire representation body.
Range = byte-ranges-specifier / other-ranges-specifier Range = byte-ranges-specifier / other-ranges-specifier
other-ranges-specifier = other-range-unit "=" other-range-set other-ranges-specifier = other-range-unit "=" other-range-set
other-range-set = 1*CHAR other-range-set = 1*CHAR
A server MAY ignore the Range header field. However, HTTP/1.1 origin A server MAY ignore the Range header field. However, origin servers
servers and intermediate caches ought to support byte ranges when and intermediate caches ought to support byte ranges when possible,
possible, since Range supports efficient recovery from partially since Range supports efficient recovery from partially failed
failed transfers, and supports efficient partial retrieval of large transfers, and supports efficient partial retrieval of large
representations. representations.
If the server supports the Range header field and the specified range If the server supports the Range header field and the specified range
or ranges are appropriate for the representation: or ranges are appropriate for the representation:
o The presence of a Range header field in an unconditional GET o The presence of a Range header field in an unconditional GET
modifies what is returned if the GET is otherwise successful. In modifies what is returned if the GET is otherwise successful. In
other words, the response carries a status code of 206 (Partial other words, the response carries a status code of 206 (Partial
Content) instead of 200 (OK). Content) instead of 200 (OK).
skipping to change at page 16, line 37 skipping to change at page 16, line 50
| Range Specifier Name | Description | Reference | | Range Specifier Name | Description | Reference |
+----------------------+-------------------+----------------------+ +----------------------+-------------------+----------------------+
| bytes | a range of octets | (this specification) | | bytes | a range of octets | (this specification) |
+----------------------+-------------------+----------------------+ +----------------------+-------------------+----------------------+
The change controller is: "IETF (iesg@ietf.org) - Internet The change controller is: "IETF (iesg@ietf.org) - Internet
Engineering Task Force". Engineering Task Force".
7. Security Considerations 7. Security Considerations
No additional security considerations have been identified beyond This section is meant to inform application developers, information
those applicable to HTTP in general [Part1]. providers, and users of the security limitations in HTTP/1.1 as
described by this document. The discussion does not include
definitive solutions to the problems revealed, though it does make
some suggestions for reducing security risks.
7.1. Overlapping Ranges
Range requests containing overlapping ranges may lead to the
situation where a server is sending far more data than the size of
the complete resource representation.
8. Acknowledgments 8. Acknowledgments
Most of the specification of ranges is based on work originally done See Section 12 of [Part1].
by Ari Luotonen and John Franks, with additional input from Steve
Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin
Hamilton, Koen Holtman, Shel Kaplan, Paul Leach, Alex Lopez-Ortiz,
Larry Masinter, Jeff Mogul, Lou Montulli, David W. Morris, Luigi
Rizzo, and Bill Weihl.
9. References 9. References
9.1. Normative References 9.1. Normative References
[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
and Message Parsing", draft-ietf-httpbis-p1-messaging-15 and Message Parsing", draft-ietf-httpbis-p1-messaging-16
(work in progress), July 2011. (work in progress), August 2011.
[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
Requests", draft-ietf-httpbis-p4-conditional-15 (work in Requests", draft-ietf-httpbis-p4-conditional-16 (work in
progress), July 2011. progress), August 2011.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996. November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
skipping to change at page 20, line 14 skipping to change at page 20, line 42
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. Compatibility with Previous Versions
B.1. Changes from RFC 2616 B.1. Changes from RFC 2616
Clarify that it is not ok to use a weak cache validator in a 206 Clarify that it is not ok to use a weak validator in a 206 response.
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 = content-range-spec Content-Range = byte-content-range-spec / other-content-range-spec
HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
If-Range = 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 1.2.2>
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
skipping to change at page 21, line 29 skipping to change at page 21, line 32
byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" ( byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" (
instance-length / "*" ) instance-length / "*" )
byte-range-resp-spec = ( first-byte-pos "-" last-byte-pos ) / "*" byte-range-resp-spec = ( first-byte-pos "-" last-byte-pos ) / "*"
byte-range-set = ( *( "," OWS ) byte-range-spec ) / ( byte-range-set = ( *( "," OWS ) byte-range-spec ) / (
suffix-byte-range-spec *( OWS "," [ ( OWS byte-range-spec ) / suffix-byte-range-spec *( OWS "," [ ( OWS byte-range-spec ) /
suffix-byte-range-spec ] ) ) suffix-byte-range-spec ] ) )
byte-range-spec = first-byte-pos "-" [ last-byte-pos ] byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
byte-ranges-specifier = bytes-unit "=" byte-range-set byte-ranges-specifier = bytes-unit "=" byte-range-set
bytes-unit = "bytes" bytes-unit = "bytes"
content-range-spec = byte-content-range-spec / entity-tag = <entity-tag, defined in [Part4], Section 2.3>
other-content-range-spec
entity-tag = <entity-tag, defined in [Part4], Section 2.2>
first-byte-pos = 1*DIGIT first-byte-pos = 1*DIGIT
instance-length = 1*DIGIT instance-length = 1*DIGIT
last-byte-pos = 1*DIGIT last-byte-pos = 1*DIGIT
other-content-range-spec = other-range-unit SP other-range-resp-spec other-content-range-spec = other-range-unit SP other-range-resp-spec
other-range-resp-spec = *CHAR other-range-resp-spec = *CHAR
other-range-set = 1*CHAR other-range-set = 1*CHAR
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 1.2.2> token = <token, defined in [Part1], Section 3.2.3>
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 25, line 23 skipping to change at page 25, line 23
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
ABNFs for header fields" ABNFs for header fields"
D.16. Since draft-ietf-httpbis-p5-range-14 D.16. Since draft-ietf-httpbis-p5-range-14
None. None.
D.17. Since draft-ietf-httpbis-p5-range-15
Closed issues:
o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/175>: "Security
consideration: range flooding"
Index Index
2 2
206 Partial Content (status code) 7 206 Partial Content (status code) 7
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 9 Content-Range header field 9
G G
Grammar Grammar
Accept-Ranges 9 Accept-Ranges 9
acceptable-ranges 9 acceptable-ranges 9
byte-content-range-spec 9 byte-content-range-spec 10
byte-range-resp-spec 9 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 6
Content-Range 9 Content-Range 10
content-range-spec 9
first-byte-pos 13 first-byte-pos 13
If-Range 12 If-Range 12
instance-length 9 instance-length 10
last-byte-pos 13 last-byte-pos 13
other-range-unit 6 other-range-unit 6
Range 14 Range 15
range-unit 6 range-unit 6
ranges-specifier 13 ranges-specifier 13
suffix-byte-range-spec 13 suffix-byte-range-spec 14
suffix-length 13 suffix-length 14
H H
Header Fields Header Fields
Accept-Ranges 9 Accept-Ranges 9
Content-Range 9 Content-Range 9
If-Range 11 If-Range 12
Range 12 Range 13
I I
If-Range header field 11 If-Range header field 12
M M
Media Type Media Type
multipart/byteranges 17 multipart/byteranges 18
multipart/x-byteranges 20 multipart/x-byteranges 20
multipart/byteranges Media Type 17 multipart/byteranges Media Type 18
multipart/x-byteranges Media Type 20 multipart/x-byteranges Media Type 20
R R
Range header field 12 Range header field 13
S S
Status Codes Status Codes
206 Partial Content 7 206 Partial Content 7
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
 End of changes. 57 change blocks. 
125 lines changed or deleted 148 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/