draft-ietf-httpbis-p5-range-08.txt   draft-ietf-httpbis-p5-range-09.txt 
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Day Software Internet-Draft Day Software
Obsoletes: 2616 (if approved) J. Gettys Obsoletes: 2616 (if approved) J. Gettys
Intended status: Standards Track One Laptop per Child Intended status: Standards Track One Laptop per Child
Expires: April 29, 2010 J. Mogul Expires: September 9, 2010 J. Mogul
HP HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Systems Adobe Systems
P. Leach P. Leach
Microsoft Microsoft
T. Berners-Lee T. Berners-Lee
W3C/MIT W3C/MIT
Y. Lafon, Ed. Y. Lafon, Ed.
W3C W3C
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
October 26, 2009 March 8, 2010
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-08 draft-ietf-httpbis-p5-range-09
Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 5 of the
seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. 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)
Discussion of this draft should take place on the HTTPBIS working
group mailing list (ietf-http-wg@w3.org). The current issues list is
at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related
documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix D.10.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
skipping to change at page 2, line 4 skipping to change at page 2, line 15
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 29, 2010. This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
The Hypertext Transfer Protocol (HTTP) is an application-level described in the BSD License.
protocol for distributed, collaborative, hypermedia information
systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 5 of the
seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. 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)
Discussion of this draft should take place on the HTTPBIS working
group mailing list (ietf-http-wg@w3.org). The current issues list is
at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related
documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix D.9. This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . 5 Specification . . . . . . . . . . . . . . . . . . . . 5
2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 5
skipping to change at page 3, line 32 skipping to change at page 3, line 32
5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 11 5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 11
5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 13 5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6.1. Status Code Registration . . . . . . . . . . . . . . . . . 14 6.1. Status Code Registration . . . . . . . . . . . . . . . . . 14
6.2. Message Header Registration . . . . . . . . . . . . . . . 14 6.2. Message Header Registration . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Internet Media Type multipart/byteranges . . . . . . 16 Appendix A. Internet Media Type multipart/byteranges . . . . . . 16
Appendix B. Compatibility with Previous Versions . . . . . . . . 18 Appendix B. Compatibility with Previous Versions . . . . . . . . 18
B.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 18 B.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 18
B.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 19 B.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 19
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 19 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 19
Appendix D. Change Log (to be removed by RFC Editor before Appendix D. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 20 publication) . . . . . . . . . . . . . . . . . . . . 20
D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 20 D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 20
D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 21 D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 21
D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 21 D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 21
D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 21 D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 21
D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 21 D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 21
D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 21 D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 21
D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 22 D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 22
D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 22 D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 22
D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 22 D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 22
D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 23
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
HTTP clients often encounter interrupted data transfers as a result HTTP clients often encounter interrupted data transfers as a result
of cancelled requests or dropped connections. When a cache has of cancelled requests or dropped connections. When a cache has
stored a partial representation, it is desirable to request the stored a partial representation, it is desirable to request the
remainder of that representation in a subsequent request rather than remainder of that representation in a subsequent request rather than
transfer the entire representation. There are also a number of Web transfer the entire representation. There are also a number of Web
skipping to change at page 7, line 13 skipping to change at page 7, line 13
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 entity-header field response SHOULD include a Content-Range entity-header field
specifying the current length of the selected resource (see specifying the current length of the selected resource (see
Section 5.2). This response MUST NOT use the multipart/byteranges Section 5.2). This response MUST NOT use the multipart/byteranges
content-type. content-type.
4. Combining Ranges 4. Combining Ranges
A response might transfer only a subrange of an entity-body, either A response might transfer only a subrange of an entity-body, either
the request included one or more Range specifications, or because a because the request included one or more Range specifications, or
connection was broken prematurely. After several such transfers, a because a connection was broken prematurely. After several such
cache might have received several ranges of the same entity-body. transfers, a cache might have received several ranges of the same
entity-body.
If a cache has a stored non-empty set of subranges for an entity, and If a cache has a stored non-empty set of subranges for an entity, and
an incoming response transfers another subrange, the cache MAY an incoming response transfers another subrange, the cache MAY
combine the new subrange with the existing set if both the following combine the new subrange with the existing set if both the following
conditions are met: conditions are met:
o Both the incoming response and the cache entry have a cache o Both the incoming response and the cache entry have a cache
validator. validator.
o The two cache validators match using the strong comparison o The two cache validators match using the strong comparison
skipping to change at page 10, line 29 skipping to change at page 10, line 33
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 entity). response containing the full entity).
If the server receives a request (other than one including an If- If the server receives a request (other than one including an If-
Range request-header field) with an unsatisfiable Range request- Range request-header field) with an unsatisfiable Range request-
header field (that is, all of whose byte-range-spec values have a 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 first-byte-pos value greater than the current length of the selected
resource), it SHOULD return a response code of 416 (Requested range resource), it SHOULD return a response code of 416 (Requested range
not satisfiable) (Section 3.2). not satisfiable) (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 request-header, since not all servers an unsatisfiable Range request-header, since not all servers
implement this request-header. implement this request-header.
5.3. If-Range 5.3. If-Range
If a client has a partial copy of an entity in its cache, and wishes If a client has a partial copy of an entity in its cache, and wishes
to have an up-to-date copy of the entire entity in its cache, it to have an up-to-date copy of the entire entity in its cache, it
could use the Range request-header with a conditional GET (using could use the Range request-header with a conditional GET (using
either or both of If-Unmodified-Since and If-Match.) However, if the either or both of If-Unmodified-Since and If-Match.) However, if the
condition fails because the entity has been modified, the client condition fails because the entity has been modified, the client
would then have to make a second request to obtain the entire current would then have to make a second request to obtain the entire current
entity-body. entity-body.
The "If-Range" request-header field allows a client to "short- The "If-Range" request-header field allows a client to "short-
circuit" the second request. Informally, its meaning is `if the circuit" the second request. Informally, its meaning is "if the
entity is unchanged, send me the part(s) that I am missing; entity is unchanged, send me the part(s) that I am missing;
otherwise, send me the entire new entity'. otherwise, send me the entire new entity".
If-Range = "If-Range" ":" OWS If-Range-v If-Range = "If-Range" ":" OWS If-Range-v
If-Range-v = entity-tag / HTTP-date If-Range-v = entity-tag / HTTP-date
If the client has no entity tag for an entity, but does have a Last- If the client has no entity tag for an entity, but does have a Last-
Modified date, it MAY use that date in an If-Range header. (The Modified date, it MAY use that date in an If-Range header. (The
server can distinguish between a valid HTTP-date and any form of server can distinguish between a valid HTTP-date and any form of
entity-tag by examining no more than two characters.) The If-Range entity-tag by examining no more than two characters.) The If-Range
header SHOULD only be used together with a Range header, and MUST be header SHOULD only be used together with a Range header, and MUST be
ignored if the request does not include a Range header, or if the ignored if the request does not include a Range header, or if the
skipping to change at page 15, line 12 skipping to change at page 15, line 17
Larry Masinter, Jeff Mogul, Lou Montulli, David W. Morris, Luigi Larry Masinter, Jeff Mogul, Lou Montulli, David W. Morris, Luigi
Rizzo, and Bill Weihl. Rizzo, and Bill Weihl.
9. References 9. References
9.1. Normative References 9.1. Normative References
[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
and Message Parsing", draft-ietf-httpbis-p1-messaging-08 and Message Parsing", draft-ietf-httpbis-p1-messaging-09
(work in progress), October 2009. (work in progress), March 2010.
[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part3] 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 3: Message Payload and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
and Content Negotiation", draft-ietf-httpbis-p3-payload-08 and Content Negotiation", draft-ietf-httpbis-p3-payload-09
(work in progress), October 2009. (work in progress), March 2010.
[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-08 (work in Requests", draft-ietf-httpbis-p4-conditional-09 (work in
progress), October 2009. progress), March 2010.
[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part6] 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.,
Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
6: Caching", draft-ietf-httpbis-p6-cache-08 (work in 6: Caching", draft-ietf-httpbis-p6-cache-09 (work in
progress), October 2009. progress), March 2010.
[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 23, line 5 skipping to change at page 23, line 5
o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/150>: o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/150>:
"multipart/byteranges for custom range units" "multipart/byteranges for custom range units"
o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/151>: "range o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/151>: "range
unit missing from other-ranges-specifier in Range header" unit missing from other-ranges-specifier in Range header"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA
registrations for optional status codes" registrations for optional status codes"
D.10. Since draft-ietf-httpbis-p5-range-08
No significant changes.
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) 6 416 Requested Range Not Satisfiable (status code) 6
A A
Accept-Ranges header 7 Accept-Ranges header 7
skipping to change at page 23, line 34 skipping to change at page 23, line 38
byte-content-range-spec 8 byte-content-range-spec 8
byte-range-resp-spec 8 byte-range-resp-spec 8
byte-range-set 11 byte-range-set 11
byte-range-spec 11 byte-range-spec 11
byte-ranges-specifier 11 byte-ranges-specifier 11
bytes-unit 5 bytes-unit 5
Content-Range 8 Content-Range 8
content-range-spec 8 content-range-spec 8
Content-Range-v 8 Content-Range-v 8
first-byte-pos 11 first-byte-pos 11
If-Range 10 If-Range 11
If-Range-v 10 If-Range-v 11
instance-length 8 instance-length 8
last-byte-pos 11 last-byte-pos 11
other-range-unit 5 other-range-unit 5
Range 13 Range 13
range-unit 5 range-unit 5
ranges-specifier 11 ranges-specifier 11
suffix-byte-range-spec 12 suffix-byte-range-spec 12
suffix-length 12 suffix-length 12
H H
 End of changes. 21 change blocks. 
57 lines changed or deleted 70 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/