| draft-ietf-httpbis-p5-range-10.txt |  | draft-ietf-httpbis-p5-range-11.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 Alcatel-Lucent |  | Intended status: Standards Track Alcatel-Lucent |
| Expires: January 13, 2011 J. Mogul |  | Expires: February 5, 2011 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 12, 2010 |  | August 4, 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-10 |  | draft-ietf-httpbis-p5-range-11 |
| 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, hypermedia 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. Part 5 defines |
| range-specific requests and the rules for constructing and combining |  | range-specific requests and the rules for constructing and combining |
| 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/3> and related |  | at <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.11. |  | The changes in this draft are summarized in Appendix D.12. |
| 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 13, 2011. |  | This Internet-Draft will expire on February 5, 2011. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2010 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 |  | 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 3, line 7 |
| 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 |  | 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 |  | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 |
| 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5 |  | 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 . . . . . . . . . . . . . . . . . . . . 5 |  | Specification . . . . . . . . . . . . . . . . . . . . 6 |
| 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 6 |
| 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5 |  | 2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 6 |
| 3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 6 |  | 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7 |
| 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 6 |  | 3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 7 |
| 4. Combining Ranges . . . . . . . . . . . . . . . . . . . . . . . 7 |  | 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 8 |
| 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 7 |  | 4. Combining Ranges . . . . . . . . . . . . . . . . . . . . . . . 8 |
| 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7 |  | 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 8 |
| 5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 8 |  | 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 9 |
| 5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 10 |  | 5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 9 |
| 5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 11 |  | 5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 11 |
| 5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 11 |  | 5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 12 |
| 5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 13 |  | 5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 12 |
| 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 |  | 5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 14 |
| 6.1. Status Code Registration . . . . . . . . . . . . . . . . . 14 |  | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 |
| 6.2. Message Header Registration . . . . . . . . . . . . . . . 14 |  | 6.1. Status Code Registration . . . . . . . . . . . . . . . . . 15 |
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 |  | 6.2. Header Field Registration . . . . . . . . . . . . . . . . 15 |
| 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 |  | 6.3. Range Specifier Registration . . . . . . . . . . . . . . . 16 |
| 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 |  | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 |
| 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 |  | 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 |
| 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 |  | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |
| Appendix A. Internet Media Type multipart/byteranges . . . . . . 16 |  | 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 |
| Appendix B. Compatibility with Previous Versions . . . . . . . . 18 |  | 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 |
| B.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 18 |  | Appendix A. Internet Media Type multipart/byteranges . . . . . . 17 |
| B.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 18 |  | Appendix B. Compatibility with Previous Versions . . . . . . . . 20 |
| Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 19 |  | B.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 20 |
|  |  | Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 20 |
| 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) . . . . . . . . . . . . . . . . . . . . 21 |
| D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 20 |  | D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 21 |
| 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 . . . . . . . . . . . 22 |
| D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 21 |  | D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 22 |
| D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 21 |  | D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 22 |
| D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 21 |  | D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 22 |
| 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 . . . . . . . . . . . 22 |  | D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 23 |
| D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 22 |  | D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 23 |
| D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 22 |  | D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 23 |
| D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 22 |  | D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 23 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 |  | D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 23 |
|  |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 29 |  | skipping to change at page 6, line 29 |
| 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> |  | 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 |  | 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. An entity can be broken down into subranges according |  | header fields. A representation can be broken down into subranges |
| to various structural units. |  | according to various structural units. |
| range-unit = bytes-unit / other-range-unit |  | range-unit = bytes-unit / other-range-unit |
| bytes-unit = "bytes" |  | bytes-unit = "bytes" |
| other-range-unit = token |  | other-range-unit = token |
| HTTP/1.1 has been designed to allow implementations of applications |  | HTTP/1.1 has been designed to allow implementations of applications |
| that do not depend on knowledge of ranges. The only range unit |  | that do not depend on knowledge of ranges. The only range unit |
| defined by HTTP/1.1 is "bytes". |  | defined by HTTP/1.1 is "bytes". Additional specifiers can be defined |
|  |  | as described in Section 2.1. |
| If a range unit is not understood in a request, a server MUST ignore |  | If a range unit is not understood in a request, a server MUST ignore |
| the whole Range header (Section 5.4). If a range unit is not |  | the whole Range header (Section 5.4). If a range unit is not |
| understood in a response, an intermediary SHOULD pass the response to |  | understood in a response, an intermediary SHOULD pass the response to |
| the client; a client MUST fail. |  | the client; a client MUST fail. |
|  |  | 2.1. Range Specifier Registry |
|  |  | The HTTP Ranger Specifier Registry defines the name space for the |
|  |  | range specifier names. |
|  |  | Registrations MUST include the following fields: |
|  |  | o Name |
|  |  | o Description |
|  |  | o Pointer to specification text |
|  |  | Values to be added to this name space are subject to IETF review |
|  |  | ([RFC5226], Section 4.1). |
|  |  | The registry itself is maintained at |
|  |  | <http://www.iana.org/assignments/http-range-specifiers>. |
| 3. Status Code Definitions |  | 3. Status Code Definitions |
| 3.1. 206 Partial Content |  | 3.1. 206 Partial Content |
| The server has fulfilled the partial GET request for the resource. |  | The server has fulfilled the partial GET request for the resource. |
| The request MUST have included a Range header field (Section 5.4) |  | The request MUST have included a Range header field (Section 5.4) |
| indicating the desired range, and MAY have included an If-Range |  | indicating the desired range, and MAY have included an If-Range |
| header field (Section 5.3) to make the request conditional. |  | header field (Section 5.3) to make the request conditional. |
| The response MUST include the following header fields: |  | The response MUST include the following header fields: |
| o Either a Content-Range header field (Section 5.2) indicating the |  | o Either a Content-Range header field (Section 5.2) indicating the |
| skipping to change at page 6, line 17 |  | skipping to change at page 7, line 34 |
| The request MUST have included a Range header field (Section 5.4) |  | The request MUST have included a Range header field (Section 5.4) |
| indicating the desired range, and MAY have included an If-Range |  | indicating the desired range, and MAY have included an If-Range |
| header field (Section 5.3) to make the request conditional. |  | header field (Section 5.3) to make the request conditional. |
| The response MUST include the following header fields: |  | The response MUST include the following header fields: |
| o Either a Content-Range header field (Section 5.2) indicating the |  | o Either a Content-Range header field (Section 5.2) indicating the |
| range included with this response, or a multipart/byteranges |  | range included with this response, or a multipart/byteranges |
| Content-Type including Content-Range fields for each part. If a |  | Content-Type including Content-Range fields for each part. If a |
| Content-Length header field is present in the response, its value |  | Content-Length header field is present in the response, its value |
| MUST match the actual number of OCTETs transmitted in the message- |  | MUST match the actual number of octets transmitted in the message- |
| body. |  | body. |
| o Date |  | o Date |
| o ETag and/or Content-Location, if the header would have been sent |  | o Cache-Control, ETag, Expires, Content-Location, Last-Modified, |
| in a 200 response to the same request |  | and/or Vary, if the header field would have been sent in a 200 |
|  |  | response to the same request |
| o Expires, Cache-Control, and/or Vary, if the field-value might |  |  |
| differ from that sent in any previous response for the same |  |  |
| variant |  |  |
| 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 entity-headers. Otherwise, the |  | response SHOULD NOT include other representation header fields. |
| response MUST include all of the entity-headers that would have been |  | Otherwise, the response MUST include all of the representation header |
| returned with a 200 (OK) response to the same request. |  | fields that would have been returned with a 200 (OK) response to the |
|  |  | same request. |
| A cache MUST NOT combine a 206 response with other previously cached |  | A cache MUST NOT combine a 206 response with other previously cached |
| content if the ETag or Last-Modified headers do not match exactly, |  | content if the ETag or Last-Modified headers do not match exactly, |
| see Section 4. |  | see Section 4. |
| A cache that does not support the Range and Content-Range headers |  | A cache that does not support the Range and Content-Range headers |
| MUST NOT cache 206 (Partial Content) responses. Furthermore, if a |  | MUST NOT cache 206 (Partial Content) responses. Furthermore, if a |
| response uses a range unit that is not understood by the cache, then |  | response uses a range unit that is not understood by the cache, then |
| it MUST NOT be cached either. |  | it MUST NOT be cached either. |
| skipping to change at page 7, line 4 |  | skipping to change at page 8, line 19 |
| 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 request-header field (Section 5.4), and none of the |  | included a Range request-header field (Section 5.4), and none of the |
| ranges-specifier values in this field overlap the current extent of |  | ranges-specifier values in this field overlap the current extent of |
| the selected resource, and the request did not include an If-Range |  | the selected resource, and the request did not include an If-Range |
| request-header field (Section 5.3). (For byte-ranges, this means |  | request-header field (Section 5.3). (For byte-ranges, this means |
| that the first-byte-pos of all of the byte-range-spec values were |  | that the first-byte-pos of all of the byte-range-spec values were |
| greater than the current length of the selected resource.) |  | greater than the 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 header field specifying the |
| specifying the current length of the selected resource (see |  | current length of the representation (see Section 5.2). This |
| Section 5.2). This response MUST NOT use the multipart/byteranges |  | 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 a representation, either |
| because the request included one or more Range specifications, or |  | because the request included one or more Range specifications, or |
| because a connection was broken prematurely. After several such |  | because a connection closed prematurely. After several such |
| transfers, a cache might have received several ranges of the same |  | transfers, a cache might have received several ranges of the same |
| entity-body. |  | representation. |
| 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 a |
| an incoming response transfers another subrange, the cache MAY |  | representation, and an incoming response transfers another subrange, |
| combine the new subrange with the existing set if both the following |  | the cache MAY combine the new subrange with the existing set if both |
| conditions are met: |  | the following 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 |
| function (see Section 4 of [Part4]). |  | function (see Section 4 of [Part4]). |
| If either requirement is not met, the cache MUST use only the most |  | If either requirement is not met, the cache MUST use only the most |
| recent partial response (based on the Date values transmitted with |  | recent partial response (based on the Date values transmitted with |
| every response, and using the incoming response if these values are |  | every response, and using the incoming response if these values are |
| equal or missing), and MUST discard the other partial information. |  | equal or missing), and MUST discard the other partial information. |
| 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. |
| For entity-header fields, both sender and recipient refer to either |  |  |
| the client or the server, depending on who sends and who receives the |  |  |
| entity. |  |  |
| 5.1. Accept-Ranges |  | 5.1. Accept-Ranges |
| The "Accept-Ranges" response-header field allows a resource to |  | The "Accept-Ranges" response-header field allows a resource to |
| indicate its acceptance of range requests. |  | 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 |
| skipping to change at page 8, line 22 |  | skipping to change at page 9, line 31 |
| 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 "Content-Range" entity-header field is sent with a partial |  | The "Content-Range" header field is sent with a partial |
| entity-body to specify where in the full entity-body the partial body |  | representation to specify where in the full representation the |
| should be applied. Range units are defined in Section 2. |  | payload body is intended to 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 8, line 42 |  | skipping to change at page 10, line 4 |
| 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 |
| other-range-resp-spec |  | other-range-resp-spec |
| other-range-resp-spec = *CHAR |  | other-range-resp-spec = *CHAR |
| The header SHOULD indicate the total length of the full entity-body, |  | The header SHOULD indicate the total length of the full |
| unless this length is unknown or difficult to determine. The |  | representation, unless this length is unknown or difficult to |
| asterisk "*" character means that the instance-length is unknown at |  | determine. The asterisk "*" character means that the instance-length |
| the time when the response was generated. |  | is unknown at the time when the response was generated. |
| Unlike byte-ranges-specifier values (see Section 5.4.1), a byte- |  | Unlike byte-ranges-specifier values (see Section 5.4.1), a byte- |
| range-resp-spec MUST only specify one range, and MUST contain |  | range-resp-spec MUST only specify one range, and MUST contain |
| absolute byte positions for both the first and last byte of the |  | absolute byte positions for both the first and last byte of the |
| range. |  | range. |
| A byte-content-range-spec with a byte-range-resp-spec whose last- |  | A byte-content-range-spec with a byte-range-resp-spec whose last- |
| byte-pos value is less than its first-byte-pos value, or whose |  | byte-pos value is less than its first-byte-pos value, or whose |
| instance-length value is less than or equal to its last-byte-pos |  | instance-length value is less than or equal to its last-byte-pos |
| value, is invalid. The recipient of an invalid byte-content-range- |  | value, is invalid. The recipient of an invalid byte-content-range- |
| spec MUST ignore it and any content transferred along with it. |  | spec MUST ignore it and any content transferred along with it. |
| In the case of a byte range request: A server sending a response with |  | In the case of a byte range request: A server sending a response with |
| status code 416 (Requested range not satisfiable) SHOULD include a |  | status code 416 (Requested range not satisfiable) SHOULD include a |
| Content-Range field with a byte-range-resp-spec of "*". The |  | Content-Range field with a byte-range-resp-spec of "*". The |
| instance-length specifies the current length of the selected |  | instance-length specifies the current length of the selected |
| resource. A response with status code 206 (Partial Content) MUST NOT |  | resource. A response with status code 206 (Partial Content) MUST NOT |
| include a Content-Range field with a byte-range-resp-spec of "*". |  | include a Content-Range field with a byte-range-resp-spec of "*". |
| Examples of byte-content-range-spec values, assuming that the entity |  | Examples of byte-content-range-spec values, assuming that the |
| contains a total of 1234 bytes: |  | representation contains a total of 1234 bytes: |
| o The first 500 bytes: |  | o The first 500 bytes: |
| bytes 0-499/1234 |  | bytes 0-499/1234 |
| o The second 500 bytes: |  | o The second 500 bytes: |
| bytes 500-999/1234 |  | bytes 500-999/1234 |
| o All except for the first 500 bytes: |  | o All except for the first 500 bytes: |
| skipping to change at page 10, line 5 |  | skipping to change at page 11, line 17 |
| Date: Wed, 15 Nov 1995 06:25:24 GMT |  | Date: Wed, 15 Nov 1995 06:25:24 GMT |
| Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT |  | Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT |
| Content-Range: bytes 21010-47021/47022 |  | Content-Range: bytes 21010-47021/47022 |
| Content-Length: 26012 |  | Content-Length: 26012 |
| Content-Type: image/gif |  | Content-Type: image/gif |
| When an HTTP message includes the content of multiple ranges (for |  | When an HTTP message includes the content of multiple ranges (for |
| example, a response to a request for multiple non-overlapping |  | example, a response to a request for multiple non-overlapping |
| ranges), these are transmitted as a multipart message. The multipart |  | ranges), these are transmitted as a multipart message. The multipart |
| 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. |
| 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 ranges in one request, the server |  | When a client requests multiple ranges in one request, the server |
| SHOULD return them in the order that they appeared in the request. |  | SHOULD return them in the order that they appeared in the 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 representation). |
| 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 a representation in its cache, and |
| to have an up-to-date copy of the entire entity in its cache, it |  | wishes to have an up-to-date copy of the entire representation in its |
| could use the Range request-header with a conditional GET (using |  | cache, it could use the Range request-header with a conditional GET |
| either or both of If-Unmodified-Since and If-Match.) However, if the |  | (using either or both of If-Unmodified-Since and If-Match.) However, |
| condition fails because the entity has been modified, the client |  | if the condition fails because the representation has been modified, |
| would then have to make a second request to obtain the entire current |  | the client would then have to make a second request to obtain the |
| entity-body. |  | entire current representation. |
| 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; |  | representation is unchanged, send me the part(s) that I am missing; |
| otherwise, send me the entire new entity". |  | otherwise, send me the entire new representation". |
| 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 a representation, but does have a |
| Modified date, it MAY use that date in an If-Range header. (The |  | Last-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 |
| cache validator for the entity, then the server SHOULD provide the |  | cache validator for the representation, then the server SHOULD |
| specified sub-range of the entity using a 206 (Partial Content) |  | provide the specified sub-range of the representation using a 206 |
| response. If the cache validator does not match, then the server |  | (Partial Content) response. If the cache validator does not match, |
| SHOULD return the entire entity using a 200 (OK) response. |  | then the server SHOULD return the entire 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 entities are represented in HTTP messages as sequences |  | Since all HTTP representations are transferred as sequences of bytes, |
| of bytes, the concept of a byte range is meaningful for any HTTP |  | the concept of a byte range is meaningful for any HTTP |
| entity. (However, not all clients and servers need to support byte- |  | representation. (However, not all clients and servers need to |
| range operations.) |  | support byte-range operations.) |
| Byte range specifications in HTTP apply to the sequence of bytes in |  | Byte range specifications in HTTP apply to the sequence of bytes in |
| the entity-body (not necessarily the same as the message-body). |  | the representation body (not necessarily the same as the message- |
|  |  | body). |
| A byte range operation MAY specify a single range of bytes, or a set |  | A byte range operation MAY specify a single range of bytes, or a set |
| of ranges within a single entity. |  | of ranges within a single representation. |
| byte-ranges-specifier = bytes-unit "=" byte-range-set |  | byte-ranges-specifier = bytes-unit "=" byte-range-set |
| byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec ) |  | byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec ) |
| byte-range-spec = first-byte-pos "-" [ last-byte-pos ] |  | byte-range-spec = first-byte-pos "-" [ last-byte-pos ] |
| first-byte-pos = 1*DIGIT |  | first-byte-pos = 1*DIGIT |
| last-byte-pos = 1*DIGIT |  | last-byte-pos = 1*DIGIT |
| The first-byte-pos value in a byte-range-spec gives the byte-offset |  | The first-byte-pos value in a byte-range-spec gives the byte-offset |
| of the first byte in a range. The last-byte-pos value gives the |  | of the first byte in a range. The last-byte-pos value gives the |
| byte-offset of the last byte in the range; that is, the byte |  | byte-offset of the last byte in the range; that is, the byte |
| positions specified are inclusive. Byte offsets start at zero. |  | positions specified are inclusive. Byte offsets start at zero. |
| If the last-byte-pos value is present, it MUST be greater than or |  | If the last-byte-pos value is present, it MUST be greater than or |
| equal to the first-byte-pos in that byte-range-spec, or the byte- |  | equal to the first-byte-pos in that byte-range-spec, or the byte- |
| range-spec is syntactically invalid. The recipient of a byte-range- |  | range-spec is syntactically invalid. The recipient of a byte-range- |
| set that includes one or more syntactically invalid byte-range-spec |  | set that includes one or more syntactically invalid byte-range-spec |
| values MUST ignore the header field that includes that byte-range- |  | values MUST ignore the header field that includes that byte-range- |
| set. |  | set. |
| If the last-byte-pos value is absent, or if the value is greater than |  | If the last-byte-pos value is absent, or if the value is greater than |
| or equal to the current length of the entity-body, last-byte-pos is |  | or equal to the current length of the representation body, last-byte- |
| taken to be equal to one less than the current length of the entity- |  | pos is taken to be equal to one less than the current length of the |
| body in bytes. |  | representation in bytes. |
| By its choice of last-byte-pos, a client can limit the number of |  | By its choice of last-byte-pos, a client can limit the number of |
| bytes retrieved without knowing the size of the entity. |  | bytes retrieved without knowing the size of the representation. |
| suffix-byte-range-spec = "-" suffix-length |  | suffix-byte-range-spec = "-" suffix-length |
| suffix-length = 1*DIGIT |  | suffix-length = 1*DIGIT |
| A suffix-byte-range-spec is used to specify the suffix of the entity- |  | A suffix-byte-range-spec is used to specify the suffix of the |
| body, of a length given by the suffix-length value. (That is, this |  | representation body, of a length given by the suffix-length value. |
| form specifies the last N bytes of an entity-body.) If the entity is |  | (That is, this form specifies the last N bytes of a representation.) |
| shorter than the specified suffix-length, the entire entity-body is |  | If the representation is shorter than the specified suffix-length, |
| used. |  | the entire representation is used. |
| If a syntactically valid byte-range-set includes at least one byte- |  | If a syntactically valid byte-range-set includes at least one byte- |
| range-spec whose first-byte-pos is less than the current length of |  | range-spec whose first-byte-pos is less than the current length of |
| the entity-body, or at least one suffix-byte-range-spec with a non- |  | the representation, or at least one suffix-byte-range-spec with a |
| zero suffix-length, then the byte-range-set is satisfiable. |  | non-zero suffix-length, then the byte-range-set is satisfiable. |
| Otherwise, the byte-range-set is unsatisfiable. If the byte-range- |  | Otherwise, the byte-range-set is unsatisfiable. If the byte-range- |
| set is unsatisfiable, the server SHOULD return a response with a |  | set is unsatisfiable, the server SHOULD return a response with a 416 |
| status of 416 (Requested range not satisfiable). Otherwise, the |  | (Requested range not satisfiable) status code. Otherwise, the server |
| server SHOULD return a response with a status of 206 (Partial |  | SHOULD return a response with a 206 (Partial Content) status code |
| Content) containing the satisfiable ranges of the entity-body. |  | containing the satisfiable ranges of the representation. |
| Examples of byte-ranges-specifier values (assuming an entity-body of |  | Examples of byte-ranges-specifier values (assuming a representation |
| length 10000): |  | of length 10000): |
| o The first 500 bytes (byte offsets 0-499, inclusive): |  | o The first 500 bytes (byte offsets 0-499, inclusive): |
| bytes=0-499 |  | bytes=0-499 |
| o The second 500 bytes (byte offsets 500-999, inclusive): |  | o The second 500 bytes (byte offsets 500-999, inclusive): |
| bytes=500-999 |  | bytes=500-999 |
| o The final 500 bytes (byte offsets 9500-9999, inclusive): |  | o The final 500 bytes (byte offsets 9500-9999, inclusive): |
| skipping to change at page 13, line 14 |  | skipping to change at page 14, line 30 |
| 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 |
| The "Range" request-header field defines the GET method (conditional |  | The "Range" request-header field defines the GET method (conditional |
| or not) to request one or more sub-ranges of the response entity- |  | or not) to request one or more sub-ranges of the response |
| body, instead of the entire entity body. |  | representation body, instead of the entire representation body. |
| 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 = 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. 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. |  | representations. |
| 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 representation: |
| o The presence of a Range header in an unconditional GET modifies |  | o The presence of a Range header in an unconditional GET modifies |
| what is returned if the GET is otherwise successful. In other |  | what is returned if the GET is otherwise successful. In other |
| words, the response carries a status code of 206 (Partial Content) |  | words, the response carries a status code of 206 (Partial Content) |
| instead of 200 (OK). |  | instead of 200 (OK). |
| o The presence of a Range header in a conditional GET (a request |  | o The presence of a Range header in a conditional GET (a request |
| using one or both of If-Modified-Since and If-None-Match, or one |  | using one or both of If-Modified-Since and If-None-Match, or one |
| or both of If-Unmodified-Since and If-Match) modifies what is |  | or both of If-Unmodified-Since and If-Match) modifies what is |
| returned if the GET is otherwise successful and the condition is |  | returned if the GET is otherwise successful and the condition is |
| true. It does not affect the 304 (Not Modified) response returned |  | true. It does not affect the 304 (Not Modified) response returned |
| if the conditional is false. |  | if the conditional is false. |
| In some cases, it might be more appropriate to use the If-Range |  | In some cases, it might be more appropriate to use the If-Range |
| 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 |
| reply, it SHOULD only return the requested range to its client. It |  | representation in reply, it SHOULD only return the requested range to |
| SHOULD store the entire received response in its cache if that is |  | its client. It SHOULD store the entire received response in its |
| consistent with its cache allocation policies. |  | cache if that is consistent with its cache allocation policies. |
| 6. IANA Considerations |  | 6. IANA Considerations |
| 6.1. Status Code Registration |  | 6.1. Status Code Registration |
| The HTTP Status Code Registry located at |  | The HTTP Status Code Registry located at |
| <http://www.iana.org/assignments/http-status-codes> should be updated |  | <http://www.iana.org/assignments/http-status-codes> shall be updated |
| with the registrations below: |  | with the registrations below: |
| +-------+---------------------------------+-------------+ |  | +-------+---------------------------------+-------------+ |
| | Value | Description | Reference | |  | | Value | Description | Reference | |
| +-------+---------------------------------+-------------+ |  | +-------+---------------------------------+-------------+ |
| | 206 | Partial Content | Section 3.1 | |  | | 206 | Partial Content | Section 3.1 | |
| | 416 | Requested Range Not Satisfiable | Section 3.2 | |  | | 416 | Requested Range Not Satisfiable | Section 3.2 | |
| +-------+---------------------------------+-------------+ |  | +-------+---------------------------------+-------------+ |
| 6.2. Message Header Registration |  | 6.2. Header Field Registration |
| The Message Header Registry located at <http://www.iana.org/ |  | The Message Header Field Registry located at <http://www.iana.org/ |
| assignments/message-headers/message-header-index.html> should be |  | assignments/message-headers/message-header-index.html> shall 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 | |
| | If-Range | http | standard | Section 5.3 | |  | | If-Range | http | standard | Section 5.3 | |
| | Range | http | standard | Section 5.4 | |  | | Range | http | standard | Section 5.4 | |
| +-------------------+----------+----------+-------------+ |  | +-------------------+----------+----------+-------------+ |
| The change controller is: "IETF (iesg@ietf.org) - Internet |  | The change controller is: "IETF (iesg@ietf.org) - Internet |
| Engineering Task Force". |  | Engineering Task Force". |
|  |  | 6.3. Range Specifier Registration |
|  |  | The registration procedure for HTTP Range Specifiers is defined by |
|  |  | Section 2.1 of this document. |
|  |  | The HTTP Range Specifier Registry shall be created at |
|  |  | <http://www.iana.org/assignments/http-range-specifiers> and be |
|  |  | populated with the registrations below: |
|  |  | +----------------------+-------------------+----------------------+ |
|  |  | | Range Specifier Name | Description | Reference | |
|  |  | +----------------------+-------------------+----------------------+ |
|  |  | | bytes | a range of octets | (this specification) | |
|  |  | +----------------------+-------------------+----------------------+ |
|  |  | The change controller is: "IETF (iesg@ietf.org) - Internet |
|  |  | Engineering Task Force". |
| 7. Security Considerations |  | 7. Security Considerations |
| No additional security considerations have been identified beyond |  | No additional security considerations have been identified beyond |
| those applicable to HTTP in general [Part1]. |  | those applicable to HTTP in general [Part1]. |
| 8. Acknowledgments |  | 8. Acknowledgments |
| Most of the specification of ranges is based on work originally done |  | Most of the specification of ranges is based on work originally done |
| by Ari Luotonen and John Franks, with additional input from Steve |  | by Ari Luotonen and John Franks, with additional input from Steve |
| Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin |  | Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin |
| skipping to change at page 15, line 4 |  | skipping to change at page 16, line 38 |
| 8. Acknowledgments |  | 8. Acknowledgments |
| Most of the specification of ranges is based on work originally done |  | Most of the specification of ranges is based on work originally done |
| by Ari Luotonen and John Franks, with additional input from Steve |  | by Ari Luotonen and John Franks, with additional input from Steve |
| Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin |  | Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin |
| Hamilton, Koen Holtman, Shel Kaplan, Paul Leach, Alex Lopez-Ortiz, |  | Hamilton, Koen Holtman, Shel Kaplan, Paul Leach, Alex Lopez-Ortiz, |
| 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-10 |  | and Message Parsing", draft-ietf-httpbis-p1-messaging-11 |
| (work in progress), July 2010. |  | (work in progress), August 2010. |
| [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  |  |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  |  |
| and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload |  |  |
| and Content Negotiation", draft-ietf-httpbis-p3-payload-10 |  |  |
| (work in progress), July 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-10 (work in |  | Requests", draft-ietf-httpbis-p4-conditional-11 (work in |
| progress), July 2010. |  | progress), August 2010. |
| [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  |  |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  |  |
| Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part |  |  |
| 6: Caching", draft-ietf-httpbis-p6-cache-10 (work in |  |  |
| progress), July 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 16, line 5 |  | skipping to change at page 17, line 28 |
| Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |  | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |
| Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |  | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |
| [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |  | [RFC3864] 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. |
| [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and |  | [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and |
| Registration Procedures", BCP 13, RFC 4288, December 2005. |  | Registration Procedures", BCP 13, RFC 4288, December 2005. |
|  |  | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an |
|  |  | IANA Considerations Section in RFCs", BCP 26, RFC 5226, |
|  |  | May 2008. |
| Appendix A. Internet Media Type multipart/byteranges |  | Appendix A. Internet Media Type multipart/byteranges |
| When an HTTP 206 (Partial Content) response message includes the |  | When an HTTP 206 (Partial Content) response message includes the |
| content of multiple ranges (a response to a request for multiple non- |  | content of multiple ranges (a response to a request for multiple non- |
| overlapping ranges), these are transmitted as a multipart message- |  | overlapping ranges), these are transmitted as a multipart message- |
| body ([RFC2046], Section 5.1). The media type for this purpose is |  | body ([RFC2046], Section 5.1). The media type for this purpose is |
| called "multipart/byteranges". The following is to be registered |  | called "multipart/byteranges". The following is to be registered |
| with IANA [RFC4288]. |  | with IANA [RFC4288]. |
| Note: Despite the name "multipart/byteranges" is not limited to |  | Note: Despite the name "multipart/byteranges" is not limited to |
| skipping to change at page 18, line 5 |  | skipping to change at page 19, line 44 |
| ...the first range... |  | ...the first range... |
| --THIS_STRING_SEPARATES |  | --THIS_STRING_SEPARATES |
| Content-type: video/example |  | Content-type: video/example |
| Content-range: exampleunit 11.2-14.3/25 |  | Content-range: exampleunit 11.2-14.3/25 |
| ...the second range |  | ...the second range |
| --THIS_STRING_SEPARATES-- |  | --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. |  | body. |
| 2. Although [RFC2046] permits the boundary string to be quoted, some |  | 2. Although [RFC2046] permits the boundary string to be quoted, some |
| existing implementations handle a quoted boundary string |  | existing implementations handle a quoted boundary string |
| incorrectly. |  | incorrectly. |
| 3. A number of browsers and servers were coded to an early draft of |  | 3. A number of browsers and servers were coded to an early draft of |
| the byteranges specification to use a media type of multipart/ |  | the byteranges specification to use a media type of multipart/ |
| x-byteranges, which is almost, but not quite compatible with the |  | x-byteranges, which is almost, but not quite compatible with the |
| version documented in HTTP/1.1. |  | version documented in HTTP/1.1. |
| Appendix B. Compatibility with Previous Versions |  | Appendix B. Compatibility with Previous Versions |
| B.1. Changes from RFC 2068 |  | B.1. Changes from RFC 2616 |
| Transfer-coding and message lengths all interact in ways that |  |  |
| required fixing exactly when chunked encoding is used (to allow for |  |  |
| transfer encoding that may not be self delimiting); it was important |  |  |
| to straighten out exactly how message lengths are computed. |  |  |
| (Section 5.2, see also [Part1], [Part3] and [Part6]) |  |  |
| There are situations where a server (especially a proxy) does not |  |  |
| know the full length of a response but is capable of serving a |  |  |
| byterange request. We therefore need a mechanism to allow byteranges |  |  |
| with a content-range not indicating the full length of the message. |  |  |
| (Section 5.2) |  |  |
| Range request responses would become very verbose if all meta-data |  |  |
| were always returned; by allowing the server to only send needed |  |  |
| headers in a 206 response, this problem can be avoided. (Section 3.1 |  |  |
| and 5.3) |  |  |
| Fix problem with unsatisfiable range requests; there are two cases: |  |  |
| syntactic problems, and range doesn't exist in the document. The 416 |  |  |
| status code was needed to resolve this ambiguity needed to indicate |  |  |
| an error for a byte range request that falls outside of the actual |  |  |
| contents of a document. (Section 3.2, 5.2) |  |  |
| B.2. 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 cache validator in a 206 |
| response. (Section 3.1) |  | response. (Section 3.1) |
| 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 = "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 6.1> |  | 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 |
| skipping to change at page 22, line 36 |  | skipping to change at page 23, line 47 |
| registrations for optional status codes" |  | registrations for optional status codes" |
| D.10. Since draft-ietf-httpbis-p5-range-08 |  | D.10. Since draft-ietf-httpbis-p5-range-08 |
| No significant changes. |  | No significant changes. |
| D.11. Since draft-ietf-httpbis-p5-range-09 |  | D.11. Since draft-ietf-httpbis-p5-range-09 |
| No significant changes. |  | No significant changes. |
|  |  | D.12. Since draft-ietf-httpbis-p5-range-10 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/69>: "Clarify |
|  |  | 'Requested Variant'" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify |
|  |  | entity / representation / variant terminology" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider |
|  |  | removing the 'changes from 2068' sections" |
|  |  | Ongoing work on Custom Ranges |
|  |  | (<http://tools.ietf.org/wg/httpbis/trac/ticket/85>): |
|  |  | o Add IANA registry. |
| Index |  | Index |
| 2 |  | 2 |
| 206 Partial Content (status code) 6 |  | 206 Partial Content (status code) 7 |
| 4 |  | 4 |
| 416 Requested Range Not Satisfiable (status code) 6 |  | 416 Requested Range Not Satisfiable (status code) 8 |
| A |  | A |
| Accept-Ranges header 7 |  | Accept-Ranges header 9 |
| C |  | C |
| Content-Range header 8 |  | Content-Range header 9 |
| G |  | G |
| Grammar |  | Grammar |
| Accept-Ranges 7 |  | Accept-Ranges 9 |
| Accept-Ranges-v 7 |  | Accept-Ranges-v 9 |
| acceptable-ranges 7 |  | acceptable-ranges 9 |
| byte-content-range-spec 8 |  | byte-content-range-spec 9 |
| byte-range-resp-spec 8 |  | byte-range-resp-spec 9 |
| byte-range-set 11 |  | byte-range-set 12 |
| byte-range-spec 11 |  | byte-range-spec 12 |
| byte-ranges-specifier 11 |  | byte-ranges-specifier 12 |
| bytes-unit 5 |  | bytes-unit 6 |
| Content-Range 8 |  | Content-Range 9 |
| content-range-spec 8 |  | content-range-spec 9 |
| Content-Range-v 8 |  | Content-Range-v 9 |
| first-byte-pos 11 |  | first-byte-pos 12 |
| If-Range 10 |  | If-Range 12 |
| If-Range-v 10 |  | If-Range-v 12 |
| instance-length 8 |  | instance-length 9 |
| last-byte-pos 11 |  | last-byte-pos 12 |
| other-range-unit 5 |  | other-range-unit 6 |
| Range 13 |  | Range 14 |
| range-unit 5 |  | range-unit 6 |
| ranges-specifier 11 |  | ranges-specifier 12 |
| suffix-byte-range-spec 12 |  | suffix-byte-range-spec 13 |
| suffix-length 12 |  | suffix-length 13 |
| H |  | H |
| Headers |  | Headers |
| Accept-Ranges 7 |  | Accept-Ranges 9 |
| Content-Range 8 |  | Content-Range 9 |
| If-Range 10 |  | If-Range 11 |
| Range 11 |  | Range 12 |
| I |  | I |
| If-Range header 10 |  | If-Range header 11 |
| M |  | M |
| Media Type |  | Media Type |
| multipart/byteranges 16 |  | multipart/byteranges 17 |
| multipart/x-byteranges 18 |  | multipart/x-byteranges 20 |
| multipart/byteranges Media Type 16 |  | multipart/byteranges Media Type 17 |
| multipart/x-byteranges Media Type 18 |  | multipart/x-byteranges Media Type 20 |
| R |  | R |
| Range header 11 |  | Range header 12 |
| S |  | S |
| Status Codes |  | Status Codes |
| 206 Partial Content 6 |  | 206 Partial Content 7 |
| 416 Requested Range Not Satisfiable 6 |  | 416 Requested Range Not Satisfiable 8 |
| Authors' Addresses |  | Authors' Addresses |
| Roy T. Fielding (editor) |  | Roy T. Fielding (editor) |
| Day Software |  | Day Software |
| 23 Corporate Plaza DR, Suite 280 |  | 23 Corporate Plaza DR, Suite 280 |
| Newport Beach, CA 92660 |  | Newport Beach, CA 92660 |
| USA |  | USA |
| Phone: +1-949-706-5300 |  | Phone: +1-949-706-5300 |
End of changes. 68 change blocks.
| 222 lines changed or deleted |  | 250 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/