draft-ietf-httpbis-p5-range-07.txt   draft-ietf-httpbis-p5-range-08.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: January 14, 2010 J. Mogul Expires: April 29, 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
July 13, 2009 October 26, 2009
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-07 draft-ietf-httpbis-p5-range-08
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. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 January 14, 2010. This Internet-Draft will expire on April 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 42 skipping to change at page 2, line 42
responses to those requests. 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). The current issues list is 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 at <http://tools.ietf.org/wg/httpbis/trac/report/11> 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.8. The changes in this draft are summarized in Appendix D.9.
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 26 skipping to change at page 3, line 26
3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 6 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 6
4. Combining Ranges . . . . . . . . . . . . . . . . . . . . . . . 7 4. Combining Ranges . . . . . . . . . . . . . . . . . . . . . . . 7
5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 7 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 7
5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 8
5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 10
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. Message Header Registration . . . . . . . . . . . . . . . 14 6.1. Status Code Registration . . . . . . . . . . . . . . . . . 14
6.2. Message Header Registration . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Internet Media Type multipart/byteranges . . . . . . 15 Appendix A. Internet Media Type multipart/byteranges . . . . . . 16
Appendix B. Compatibility with Previous Versions . . . . . . . . 17 Appendix B. Compatibility with Previous Versions . . . . . . . . 18
B.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 17 B.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 18
B.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 18 B.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 19
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 18 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) . . . . . . . . . . . . . . . . . . . . 19 publication) . . . . . . . . . . . . . . . . . . . . 20
D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 19 D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 20
D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 20 D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 21
D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 20 D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 21
D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 20 D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 21
D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 20 D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 21
D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 20 D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 21
D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 21 D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 22
D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 21 D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 22
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
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
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
skipping to change at page 5, line 22 skipping to change at page 5, line 22
The core rules below are defined in Section 1.2.2 of [Part1]: The core rules below are defined in Section 1.2.2 of [Part1]:
token = <token, defined in [Part1], Section 1.2.2> 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>
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 3.2> HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
entity-tag = <entity-tag, defined in [Part4], Section 2> entity-tag = <entity-tag, defined in [Part4], Section 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
response entity be included within the response. HTTP/1.1 uses range response entity 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. An entity can be broken down into subranges according header fields. An entity can be broken down into subranges according
to various structural units. to various structural units.
skipping to change at page 7, line 44 skipping to change at page 7, line 44
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.
For entity-header fields, both sender and recipient refer to either For entity-header fields, both sender and recipient refer to either
the client or the server, depending on who sends and who receives the the client or the server, depending on who sends and who receives the
entity. entity.
5.1. Accept-Ranges 5.1. Accept-Ranges
The response-header "Accept-Ranges" field allows the server to The "Accept-Ranges" response-header field allows a resource to
indicate its acceptance of range requests for a resource: indicate its acceptance of range requests.
Accept-Ranges = "Accept-Ranges" ":" OWS Accept-Ranges-v Accept-Ranges = "Accept-Ranges" ":" OWS Accept-Ranges-v
Accept-Ranges-v = acceptable-ranges Accept-Ranges-v = acceptable-ranges
acceptable-ranges = 1#range-unit / "none" acceptable-ranges = 1#range-unit / "none"
Origin servers that accept byte-range requests MAY send Origin servers that accept byte-range requests MAY send
Accept-Ranges: bytes Accept-Ranges: bytes
but are not required to do so. Clients MAY generate range requests but are not required to do so. Clients MAY generate range requests
skipping to change at page 8, line 22 skipping to change at page 8, line 22
Servers that do not accept any kind of range request for a resource Servers that do not accept any kind of range request for a resource
MAY send MAY send
Accept-Ranges: none Accept-Ranges: none
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 entity-header "Content-Range" is sent with a partial entity-body The "Content-Range" entity-header field is sent with a partial
to specify where in the full entity-body the partial body should be entity-body to specify where in the full entity-body the partial body
applied. Range units are defined in Section 2. should be applied. Range units are defined in Section 2.
Content-Range = "Content-Range" ":" OWS Content-Range-v Content-Range = "Content-Range" ":" OWS Content-Range-v
Content-Range-v = content-range-spec Content-Range-v = content-range-spec
content-range-spec = 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 / "*" )
skipping to change at page 10, line 14 skipping to change at page 10, line 14
media type used for this purpose is "multipart/byteranges" as defined media type used for this purpose is "multipart/byteranges" as defined
in Appendix A. See Appendix B.1 for a compatibility issue. in Appendix A. See Appendix B.1 for a compatibility issue.
A response to a request for a single range MUST NOT be sent using the A response to a request for a single range MUST NOT be sent using the
multipart/byteranges media type. A response to a request for multipart/byteranges media type. A response to a request for
multiple ranges, whose result is a single range, MAY be sent as a multiple ranges, whose result is a single range, MAY be sent as a
multipart/byteranges media type with one part. A client that cannot multipart/byteranges media type with one part. A client that cannot
decode a multipart/byteranges message MUST NOT ask for multiple decode a multipart/byteranges message MUST NOT ask for multiple
ranges in a single request. ranges in a single request.
When a client requests multiple byte-ranges in one request, the When a client requests multiple ranges in one request, the server
server SHOULD return them in the order that they appeared in the SHOULD return them in the order that they appeared in the request.
request.
If the server ignores a byte-range-spec because it is syntactically If the server ignores a byte-range-spec because it is syntactically
invalid, the server SHOULD treat the request as if the invalid Range 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 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
skipping to change at page 10, line 45 skipping to change at page 10, line 44
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 request header "If-Range" allows a client to "short-circuit" the The "If-Range" request-header field allows a client to "short-
second request. Informally, its meaning is `if the entity is circuit" the second request. Informally, its meaning is `if the
unchanged, send me the part(s) that I am missing; otherwise, send me entity is unchanged, send me the part(s) that I am missing;
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
server does not support the sub-range operation. server does not support the sub-range operation.
If the entity tag given in the If-Range header matches the current If the entity tag given in the If-Range header matches the current
entity tag for the entity, then the server SHOULD provide the cache validator for the entity, then the server SHOULD provide the
specified sub-range of the entity using a 206 (Partial Content) specified sub-range of the entity using a 206 (Partial Content)
response. If the entity tag does not match, then the server SHOULD response. If the cache validator does not match, then the server
return the entire entity using a 200 (OK) response. SHOULD return the entire entity using a 200 (OK) response.
5.4. Range 5.4. Range
5.4.1. Byte Ranges 5.4.1. Byte Ranges
Since all HTTP entities are represented in HTTP messages as sequences Since all HTTP entities are represented in HTTP messages as sequences
of bytes, the concept of a byte range is meaningful for any HTTP of bytes, the concept of a byte range is meaningful for any HTTP
entity. (However, not all clients and servers need to support byte- entity. (However, not all clients and servers need to support byte-
range operations.) range operations.)
skipping to change at page 13, line 13 skipping to change at page 13, line 13
bytes=0-0,-1 bytes=0-0,-1
o Several legal but not canonical specifications of the second 500 o Several legal but not canonical specifications of the second 500
bytes (byte offsets 500-999, inclusive): bytes (byte offsets 500-999, inclusive):
bytes=500-600,601-999 bytes=500-600,601-999
bytes=500-700,601-999 bytes=500-700,601-999
5.4.2. Range Retrieval Requests 5.4.2. Range Retrieval Requests
HTTP retrieval requests using conditional or unconditional GET The "Range" request-header field defines the GET method (conditional
methods MAY request one or more sub-ranges of the entity, instead of or not) to request one or more sub-ranges of the response entity-
the entire entity, using the Range request header, which applies to body, instead of the entire entity body.
the entity returned as the result of the request:
Range = "Range" ":" OWS Range-v Range = "Range" ":" OWS Range-v
Range-v = byte-ranges-specifier Range-v = byte-ranges-specifier
/ other-ranges-specifier / other-ranges-specifier
other-ranges-specifier = 1*CHAR other-ranges-specifier = other-range-unit "=" other-range-set
other-range-set = 1*CHAR
A server MAY ignore the Range header. However, HTTP/1.1 origin A server MAY ignore the Range header. However, HTTP/1.1 origin
servers and intermediate caches ought to support byte ranges when servers and intermediate caches ought to support byte ranges when
possible, since Range supports efficient recovery from partially possible, since Range supports efficient recovery from partially
failed transfers, and supports efficient partial retrieval of large failed transfers, and supports efficient partial retrieval of large
entities. entities.
If the server supports the Range header and the specified range or If the server supports the Range header and the specified range or
ranges are appropriate for the entity: ranges are appropriate for the entity:
skipping to change at page 14, line 7 skipping to change at page 14, line 7
header (see Section 5.3) in addition to the Range header. header (see Section 5.3) in addition to the Range header.
If a proxy that supports ranges receives a Range request, forwards If a proxy that supports ranges receives a Range request, forwards
the request to an inbound server, and receives an entire entity in the request to an inbound server, and receives an entire entity in
reply, it SHOULD only return the requested range to its client. It reply, it SHOULD only return the requested range to its client. It
SHOULD store the entire received response in its cache if that is SHOULD store the entire received response in its cache if that is
consistent with its cache allocation policies. consistent with its cache allocation policies.
6. IANA Considerations 6. IANA Considerations
6.1. Message Header Registration 6.1. Status Code Registration
The HTTP Status Code Registry located at
<http://www.iana.org/assignments/http-status-codes> should be updated
with the registrations below:
+-------+---------------------------------+-------------+
| Value | Description | Reference |
+-------+---------------------------------+-------------+
| 206 | Partial Content | Section 3.1 |
| 416 | Requested Range Not Satisfiable | Section 3.2 |
+-------+---------------------------------+-------------+
6.2. Message Header Registration
The Message Header Registry located at <http://www.iana.org/ The Message Header Registry located at <http://www.iana.org/
assignments/message-headers/message-header-index.html> should be assignments/message-headers/message-header-index.html> should be
updated with the permanent registrations below (see [RFC3864]): updated with the permanent registrations below (see [RFC3864]):
+-------------------+----------+----------+-------------+ +-------------------+----------+----------+-------------+
| Header Field Name | Protocol | Status | Reference | | Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-------------+ +-------------------+----------+----------+-------------+
| Accept-Ranges | http | standard | Section 5.1 | | Accept-Ranges | http | standard | Section 5.1 |
| Content-Range | http | standard | Section 5.2 | | Content-Range | http | standard | Section 5.2 |
skipping to change at page 14, line 46 skipping to change at page 15, line 12
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-07 and Message Parsing", draft-ietf-httpbis-p1-messaging-08
(work in progress), July 2009. (work in progress), October 2009.
[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-07 and Content Negotiation", draft-ietf-httpbis-p3-payload-08
(work in progress), July 2009. (work in progress), October 2009.
[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-07 (work in Requests", draft-ietf-httpbis-p4-conditional-08 (work in
progress), July 2009. progress), October 2009.
[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-07 (work in 6: Caching", draft-ietf-httpbis-p6-cache-08 (work in
progress), July 2009. progress), October 2009.
[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 16, line 6 skipping to change at page 16, line 17
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
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
each body-part. each body-part.
Type name: multipart Type name: multipart
Subtype name: byteranges Subtype name: byteranges
Required parameters: boundary Required parameters: boundary
skipping to change at page 17, line 23 skipping to change at page 18, line 5
Content-range: bytes 500-999/8000 Content-range: bytes 500-999/8000
...the first range... ...the first range...
--THIS_STRING_SEPARATES --THIS_STRING_SEPARATES
Content-type: application/pdf Content-type: application/pdf
Content-range: bytes 7000-7999/8000 Content-range: bytes 7000-7999/8000
...the second range ...the second range
--THIS_STRING_SEPARATES-- --THIS_STRING_SEPARATES--
Other example:
HTTP/1.1 206 Partial Content
Date: Tue, 14 Nov 1995 06:25:24 GMT
Last-Modified: Tue, 14 July 04:58:08 GMT
Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
--THIS_STRING_SEPARATES
Content-type: video/example
Content-range: exampleunit 1.2-4.3/25
...the first range...
--THIS_STRING_SEPARATES
Content-type: video/example
Content-range: exampleunit 11.2-14.3/25
...the second range
--THIS_STRING_SEPARATES--
Notes: Notes:
1. Additional CRLFs may precede the first boundary string in the 1. Additional CRLFs may precede the first boundary string in the
entity. entity.
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
skipping to change at page 18, line 34 skipping to change at page 19, line 34
(Appendix A) (Appendix A)
Appendix C. Collected ABNF Appendix C. Collected ABNF
Accept-Ranges = "Accept-Ranges:" OWS Accept-Ranges-v Accept-Ranges = "Accept-Ranges:" OWS Accept-Ranges-v
Accept-Ranges-v = acceptable-ranges Accept-Ranges-v = acceptable-ranges
Content-Range = "Content-Range:" OWS Content-Range-v Content-Range = "Content-Range:" OWS Content-Range-v
Content-Range-v = content-range-spec Content-Range-v = content-range-spec
HTTP-date = <HTTP-date, defined in [Part1], Section 3.2> HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
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
OWS = <OWS, defined in [Part1], Section 1.2.2> OWS = <OWS, defined in [Part1], Section 1.2.2>
Range = "Range:" OWS Range-v Range = "Range:" OWS Range-v
Range-v = byte-ranges-specifier / other-ranges-specifier Range-v = 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 19, line 24 skipping to change at page 20, line 24
entity-tag = <entity-tag, defined in [Part4], Section 2> entity-tag = <entity-tag, defined in [Part4], Section 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-unit = token other-range-unit = token
other-ranges-specifier = 1*CHAR 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 1.2.2>
ABNF diagnostics: ABNF diagnostics:
skipping to change at page 21, line 38 skipping to change at page 22, line 38
o Add appendix containing collected and expanded ABNF, reorganize o Add appendix containing collected and expanded ABNF, reorganize
ABNF introduction. ABNF introduction.
D.8. Since draft-ietf-httpbis-p5-range-06 D.8. Since draft-ietf-httpbis-p5-range-06
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for
numeric protocol elements" numeric protocol elements"
D.9. Since draft-ietf-httpbis-p5-range-07
Closed issues:
o Fixed discrepancy in the If-Range definition about allowed
validators.
o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/150>:
"multipart/byteranges for custom range units"
o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/151>: "range
unit missing from other-ranges-specifier in Range header"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA
registrations for optional status codes"
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 22, line 43 skipping to change at page 24, line 8
Accept-Ranges 7 Accept-Ranges 7
Content-Range 8 Content-Range 8
If-Range 10 If-Range 10
Range 11 Range 11
I I
If-Range header 10 If-Range header 10
M M
Media Type Media Type
multipart/byteranges 15 multipart/byteranges 16
multipart/x-byteranges 17 multipart/x-byteranges 18
multipart/byteranges Media Type 15 multipart/byteranges Media Type 16
multipart/x-byteranges Media Type 17 multipart/x-byteranges Media Type 18
R R
Range header 11 Range header 11
S S
Status Codes Status Codes
206 Partial Content 6 206 Partial Content 6
416 Requested Range Not Satisfiable 6 416 Requested Range Not Satisfiable 6
Authors' Addresses Authors' Addresses
 End of changes. 30 change blocks. 
60 lines changed or deleted 113 lines changed or added

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