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