p5-range.unpg.txt   rfc7233-to-be.unpg.txt 
HTTPbis Working Group R. Fielding, Ed. Internet Engineering Task Force (IETF) R. Fielding, Ed.
Internet-Draft Adobe Request for Comments: 7233 Adobe
Obsoletes: 2616 (if approved) Y. Lafon, Ed. Obsoletes: 2616 Y. Lafon, Ed.
Intended status: Standards Track W3C Category: Standards Track W3C
Expires: November 29, 2014 J. Reschke, Ed. ISSN: 2070-1721 J. Reschke, Ed.
greenbytes greenbytes
May 28, 2014 May 2014
Hypertext Transfer Protocol (HTTP/1.1): Range Requests Hypertext Transfer Protocol (HTTP/1.1): Range Requests
draft-ietf-httpbis-p5-range-latest
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level protocol for distributed, collaborative, hypertext information level protocol for distributed, collaborative, hypertext information
systems. This document defines range requests and the rules for systems. This document defines range requests and the rules for
constructing and combining responses to those requests. constructing and combining responses to those requests.
Editorial Note (To be removed by RFC Editor)
Discussion of this draft takes place on the HTTPBIS working group
mailing list (ietf-http-wg@w3.org), which is archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
The current issues list is at
<http://tools.ietf.org/wg/httpbis/trac/report/3> and related
documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>.
_This is a temporary document for the purpose of tracking the
editorial changes made during the AUTH48 (RFC publication) phase._
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at http://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference http://www.rfc-editor.org/info/rfc7233.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 29, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 7 skipping to change at page 2, line 17
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 3
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 3
2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Other Range Units . . . . . . . . . . . . . . . . . . . . 7 2.2. Other Range Units . . . . . . . . . . . . . . . . . . . . 6
2.3. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 6
3. Range Requests . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Range Requests . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Responses to a Range Request . . . . . . . . . . . . . . . . . 10 4. Responses to a Range Request . . . . . . . . . . . . . . . . . 9
4.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 10 4.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 9
4.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Combining Ranges . . . . . . . . . . . . . . . . . . . . . 14 4.3. Combining Ranges . . . . . . . . . . . . . . . . . . . . . 13
4.4. 416 Range Not Satisfiable . . . . . . . . . . . . . . . . 15 4.4. 416 Range Not Satisfiable . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
5.1. Range Unit Registry . . . . . . . . . . . . . . . . . . . 15 5.1. Range Unit Registry . . . . . . . . . . . . . . . . . . . 14
5.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 15 5.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 14
5.1.2. Registrations . . . . . . . . . . . . . . . . . . . . 16 5.1.2. Registrations . . . . . . . . . . . . . . . . . . . . 15
5.2. Status Code Registration . . . . . . . . . . . . . . . . . 16 5.2. Status Code Registration . . . . . . . . . . . . . . . . . 15
5.3. Header Field Registration . . . . . . . . . . . . . . . . 16 5.3. Header Field Registration . . . . . . . . . . . . . . . . 15
5.4. Internet Media Type Registration . . . . . . . . . . . . . 17 5.4. Internet Media Type Registration . . . . . . . . . . . . . 16
5.4.1. Internet Media Type multipart/byteranges . . . . . . . 17 5.4.1. Internet Media Type multipart/byteranges . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6.1. Denial-of-Service Attacks Using Range . . . . . . . . . . 18 6.1. Denial-of-Service Attacks Using Range . . . . . . . . . . 17
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 19 8.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Internet Media Type multipart/byteranges . . . . . . 20 Appendix A. Internet Media Type multipart/byteranges . . . . . . 19
Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 21 Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 20
Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 21 Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 20
Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 21 Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 20
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Hypertext Transfer Protocol (HTTP) clients often encounter Hypertext Transfer Protocol (HTTP) clients often encounter
interrupted data transfers as a result of canceled requests or interrupted data transfers as a result of canceled requests or
dropped connections. When a client has stored a partial dropped connections. When a client has stored a partial
representation, it is desirable to request the remainder of that representation, it is desirable to request the remainder of that
representation in a subsequent request rather than transfer the representation in a subsequent request rather than transfer the
entire representation. Likewise, devices with limited local storage entire representation. Likewise, devices with limited local storage
might benefit from being able to request only a subset of a larger might benefit from being able to request only a subset of a larger
skipping to change at page 9, line 23 skipping to change at page 8, line 23
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 as follows: if the second request. Informally, its meaning is as follows: if the
representation is unchanged, send me the part(s) that I am requesting representation is unchanged, send me the part(s) that I am requesting
in Range; otherwise, send me the entire representation. in Range; otherwise, send me the entire representation.
If-Range = entity-tag / HTTP-date If-Range = entity-tag / HTTP-date
A client MUST NOT generate an If-Range header field in a request that A client MUST NOT generate an If-Range header field in a request that
does not contain a Range header field. A server MUST ignore an If- does not contain a Range header field. A server MUST ignore an
Range header field received in a request that does not contain a If-Range header field received in a request that does not contain a
Range header field. An origin server MUST ignore an If-Range header Range header field. An origin server MUST ignore an If-Range header
field received in a request for a target resource that does not field received in a request for a target resource that does not
support Range requests. support Range requests.
A client MUST NOT generate an If-Range header field containing an A client MUST NOT generate an If-Range header field containing an
entity-tag that is marked as weak. A client MUST NOT generate an If- entity-tag that is marked as weak. A client MUST NOT generate an If-
Range header field containing an HTTP-date unless the client has no Range header field containing an HTTP-date unless the client has no
entity-tag for the corresponding representation and the date is a entity-tag for the corresponding representation and the date is a
strong validator in the sense defined by Section 2.2.2 of [RFC7232]. strong validator in the sense defined by Section 2.2.2 of [RFC7232].
skipping to change at page 9, line 49 skipping to change at page 8, line 49
defined by Section 2.2.2 of [RFC7232]. A valid entity-tag can be defined by Section 2.2.2 of [RFC7232]. A valid entity-tag can be
distinguished from a valid HTTP-date by examining the first two distinguished from a valid HTTP-date by examining the first two
characters for a DQUOTE. characters for a DQUOTE.
If the validator given in the If-Range header field matches the If the validator given in the If-Range header field matches the
current validator for the selected representation of the target current validator for the selected representation of the target
resource, then the server SHOULD process the Range header field as resource, then the server SHOULD process the Range header field as
requested. If the validator does not match, the server MUST ignore requested. If the validator does not match, the server MUST ignore
the Range header field. Note that this comparison by exact match, the Range header field. Note that this comparison by exact match,
including when the validator is an HTTP-date, differs from the including when the validator is an HTTP-date, differs from the
"earlier than or equal to" comparison used when evaluating an If- "earlier than or equal to" comparison used when evaluating an
Unmodified-Since conditional. If-Unmodified-Since conditional.
4. Responses to a Range Request 4. Responses to a Range Request
4.1. 206 Partial Content 4.1. 206 Partial Content
The 206 (Partial Content) status code indicates that the server is The 206 (Partial Content) status code indicates that the server is
successfully fulfilling a range request for the target resource by successfully fulfilling a range request for the target resource by
transferring one or more parts of the selected representation that transferring one or more parts of the selected representation that
correspond to the satisfiable ranges found in the request's Range correspond to the satisfiable ranges found in the request's Range
header field (Section 3.1). header field (Section 3.1).
skipping to change at page 19, line 18 skipping to change at page 18, line 18
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.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
draft-ietf-httpbis-p1-messaging-latest (work in progress), RFC 7230, May 2014.
May 2014.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
draft-ietf-httpbis-p2-semantics-latest (work in progress),
May 2014. May 2014.
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Conditional Requests", Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
draft-ietf-httpbis-p4-conditional-latest (work in May 2014.
progress), May 2014.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
draft-ietf-httpbis-p6-cache-latest (work in progress), RFC 7234, May 2014.
May 2014.
8.2. Informative References 8.2. Informative References
[BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
RFC 6838, January 2013. RFC 6838, January 2013.
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004. September 2004.
skipping to change at page 23, line 8 skipping to change at page 22, line 8
suffix-byte-range-spec = "-" suffix-length suffix-byte-range-spec = "-" suffix-length
suffix-length = 1*DIGIT suffix-length = 1*DIGIT
token = <token, see [RFC7230], Section 3.2.6> token = <token, see [RFC7230], Section 3.2.6>
unsatisfied-range = "*/" complete-length unsatisfied-range = "*/" complete-length
Index Index
2 2
206 Partial Content (status code) 10 206 Partial Content (status code) 9
4 4
416 Range Not Satisfiable (status code) 15 416 Range Not Satisfiable (status code) 14
A A
Accept-Ranges header field 7 Accept-Ranges header field 6
C C
Content-Range header field 12 Content-Range header field 11
G G
Grammar Grammar
Accept-Ranges 7 Accept-Ranges 6
acceptable-ranges 7 acceptable-ranges 6
byte-content-range 12 byte-content-range 11
byte-range 12 byte-range 11
byte-range-resp 12 byte-range-resp 11
byte-range-set 5 byte-range-set 4
byte-range-spec 5 byte-range-spec 4
byte-ranges-specifier 5 byte-ranges-specifier 4
bytes-unit 5 bytes-unit 4
complete-length 12 complete-length 11
Content-Range 12 Content-Range 11
first-byte-pos 5 first-byte-pos 4
If-Range 9 If-Range 8
last-byte-pos 5 last-byte-pos 4
other-content-range 12 other-content-range 11
other-range-resp 12 other-range-resp 11
other-range-unit 5, 7 other-range-unit 4, 6
Range 7 Range 6
range-unit 5 range-unit 4
ranges-specifier 5 ranges-specifier 4
suffix-byte-range-spec 6 suffix-byte-range-spec 5
suffix-length 6 suffix-length 5
unsatisfied-range 12 unsatisfied-range 11
I I
If-Range header field 9 If-Range header field 8
M M
Media Type Media Type
multipart/byteranges 17, 20 multipart/byteranges 16, 19
multipart/x-byteranges 20 multipart/x-byteranges 19
multipart/byteranges Media Type 17, 20 multipart/byteranges Media Type 16, 19
multipart/x-byteranges Media Type 20 multipart/x-byteranges Media Type 19
R R
Range header field 7 Range header field 6
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. 22 change blocks. 
112 lines changed or deleted 91 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/