| draft-ietf-httpbis-p5-range-00.txt |  | draft-ietf-httpbis-p5-range-01.txt |
--- | --- | --- | --- | ---
| Network Working Group R. Fielding, Ed. |  | Network Working Group R. Fielding, Ed. |
| Internet-Draft Day Software |  | Internet-Draft Day Software |
| Obsoletes: 2068, 2616 J. Gettys |  | Obsoletes: 2616 (if approved) J. Gettys |
| (if approved) One Laptop per Child |  | Intended status: Standards Track One Laptop per Child |
| Intended status: Standards Track J. Mogul |  | Expires: July 15, 2008 J. Mogul |
| Expires: June 22, 2008 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 |
| December 20, 2007 |  | Y. Lafon, Ed. |
|  |  | W3C |
|  |  | J. Reschke, Ed. |
|  |  | greenbytes |
|  |  | January 12, 2008 |
| 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-00 |  | draft-ietf-httpbis-p5-range-01 |
| Status of this Memo |  | Status of this Memo |
| By submitting this Internet-Draft, each author represents that any |  | By submitting this Internet-Draft, each author represents that any |
| applicable patent or other IPR claims of which he or she is aware |  | applicable patent or other IPR claims of which he or she is aware |
| have been or will be disclosed, and any of which he or she becomes |  | have been or will be disclosed, and any of which he or she becomes |
| aware will be disclosed, in accordance with Section 6 of BCP 79. |  | aware will be disclosed, in accordance with Section 6 of BCP 79. |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF), its areas, and its working groups. Note that |  | Task Force (IETF), its areas, and its working groups. Note that |
| skipping to change at page 1, line 45 |  | skipping to change at page 1, line 49 |
| and may be updated, replaced, or obsoleted by other documents at any |  | and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |  | time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |  | material or to cite them other than as "work in progress." |
| The list of current Internet-Drafts can be accessed at |  | The list of current Internet-Drafts can be accessed at |
| http://www.ietf.org/ietf/1id-abstracts.txt. |  | http://www.ietf.org/ietf/1id-abstracts.txt. |
| The list of Internet-Draft Shadow Directories can be accessed at |  | The list of Internet-Draft Shadow Directories can be accessed at |
| http://www.ietf.org/shadow.html. |  | http://www.ietf.org/shadow.html. |
| This Internet-Draft will expire on June 22, 2008. |  | This Internet-Draft will expire on July 15, 2008. |
| Copyright Notice |  | Copyright Notice |
| Copyright (C) The IETF Trust (2007). |  | Copyright (C) The IETF Trust (2008). |
| 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) |
| This version of the HTTP specification contains only minimal |  |  |
| editorial changes from [RFC2616] (abstract, introductory paragraph, |  |  |
| and authors' addresses). All other changes are due to partitioning |  |  |
| the original into seven mostly independent parts. The intent is for |  |  |
| readers of future drafts to able to use draft 00 as the basis for |  |  |
| comparison when the WG makes later changes to the specification text. |  |  |
| This draft will shortly be followed by draft 01 (containing the first |  |  |
| round of changes that have already been agreed to on the mailing |  |  |
| list). There is no point in reviewing this draft other than to |  |  |
| verify that the partitioning has been done correctly. Roy T. |  |  |
| Fielding, Yves Lafon, and Julian Reschke will be the editors after |  |  |
| draft 00 is submitted. |  |  |
| 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://www3.tools.ietf.org/wg/httpbis/trac/report/11> and related |  | at <http://www.tools.ietf.org/wg/httpbis/trac/report/11> and related |
| documents (including fancy diffs) can be found at |  | documents (including fancy diffs) can be found at |
| <http://www3.tools.ietf.org/wg/httpbis/>. |  | <http://www.tools.ietf.org/wg/httpbis/>. |
|  |  | This draft incorporates those issue resolutions that were either |
|  |  | collected in the original RFC2616 errata list |
|  |  | (<http://purl.org/NET/http-errata>), or which were agreed upon on the |
|  |  | mailing list between October 2006 and November 2007 (as published in |
|  |  | "draft-lafon-rfc2616bis-03"). |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 |
|  |  | 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 |
| 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 4 |  | 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 4 |
| 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 4 |  | 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5 |
| 3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 4 |  | 3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 5 |
| 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 5 |  | 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 6 |
| 4. Combining Byte Ranges . . . . . . . . . . . . . . . . . . . . 5 |  | 4. Combining Byte Ranges . . . . . . . . . . . . . . . . . . . . 6 |
| 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 6 |  | 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 6 |
| 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 6 |  | 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7 |
| 5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 7 |  | 5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 7 |
| 5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 9 |  | 5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 9 |
| 5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 9 |  | 5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 10 |
| 5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 9 |  | 5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 10 |
| 5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 11 |  | 5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 12 |
| 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 |  | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 |
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 |  | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 |
| 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 |  | 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 |
| 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 |  | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 |
| Appendix A. Internet Media Type multipart/byteranges . . . . . . 13 |  | 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 |
| Appendix B. Changes from RFC 2068 . . . . . . . . . . . . . . . . 14 |  | 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 |  | Appendix A. Internet Media Type multipart/byteranges . . . . . . 14 |
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 |  | Appendix B. Compatibility with Previous Versions . . . . . . . . 15 |
| Intellectual Property and Copyright Statements . . . . . . . . . . 18 |  | B.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 15 |
|  |  | B.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 16 |
|  |  | Appendix C. Change Log (to be removed by RFC Editor before |
|  |  | publication) . . . . . . . . . . . . . . . . . . . . 16 |
|  |  | C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 16 |
|  |  | C.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 16 |
|  |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |
|  |  | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 |
|  |  | Intellectual Property and Copyright Statements . . . . . . . . . . 21 |
| 1. Introduction |  | 1. Introduction |
| This document will define aspects of HTTP related to range requests, |  | HTTP clients often encounter interrupted data transfers as a result |
| partial responses, and the multipart/byteranges media type. Right |  | of cancelled requests or dropped connections. When a cache has |
| now it only includes the extracted relevant sections of RFC 2616 |  | stored a partial representation, it is desirable to request the |
| [RFC2616] without edit. |  | remainder of that representation in a subsequent request rather than |
|  |  | transfer the entire representation. There are also a number of Web |
|  |  | applications that benefit from being able to request only a subset of |
|  |  | 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 |
|  |  | limited local storage. |
|  |  | This document defines HTTP/1.1 range requests, partial responses, and |
|  |  | the multipart/byteranges media type. The protocol for range requests |
|  |  | is an OPTIONAL feature of HTTP, designed so resources or recipients |
|  |  | that do not implement this feature can respond as if it is a normal |
|  |  | GET request without impacting interoperability. Partial responses |
|  |  | are indicated by a distinct status code to not be mistaken for full |
|  |  | responses by intermediate caches that might not implement the |
|  |  | feature. |
|  |  | Although the HTTP range request mechanism is designed to allow for |
|  |  | extensible range types, this specification only defines requests for |
|  |  | byte ranges. |
|  |  | 1.1. Requirements |
|  |  | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
|  |  | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
|  |  | document are to be interpreted as described in [RFC2119]. |
|  |  | An implementation is not compliant if it fails to satisfy one or more |
|  |  | of the MUST or REQUIRED level requirements for the protocols it |
|  |  | implements. An implementation that satisfies all the MUST or |
|  |  | REQUIRED level and all the SHOULD level requirements for its |
|  |  | protocols is said to be "unconditionally compliant"; one that |
|  |  | satisfies all the MUST level requirements but not all the SHOULD |
|  |  | level requirements for its protocols is said to be "conditionally |
|  |  | compliant." |
| 2. Range Units |  | 2. Range Units |
| HTTP/1.1 allows a client to request that only part (a range of) the |  | HTTP/1.1 allows a client to request that only part (a range of) the |
| response entity be included within the response. HTTP/1.1 uses range |  | response entity be included within the response. HTTP/1.1 uses range |
| units in the Range (Section 5.4) and Content-Range (Section 5.2) |  | units in the Range (Section 5.4) and Content-Range (Section 5.2) |
| header fields. An entity can be broken down into subranges according |  | header fields. An entity can be broken down into subranges according |
| to various structural units. |  | to various structural units. |
| range-unit = bytes-unit | other-range-unit |  | range-unit = bytes-unit | other-range-unit |
| skipping to change at page 5, line 4 |  | skipping to change at page 5, line 34 |
| 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 ETag and/or Content-Location, if the header would have been sent |
| in a 200 response to the same request |  | in a 200 response to the same request |
| o Expires, Cache-Control, and/or Vary, if the field-value might |  | o Expires, Cache-Control, and/or Vary, if the field-value might |
| differ from that sent in any previous response for the same |  | differ from that sent in any previous response for the same |
| variant |  | variant |
| If the 206 response is the result of an If-Range request that used a |  | If the 206 response is the result of an If-Range request, the |
| strong cache validator (see Section 4 of [Part4]), the response |  | response SHOULD NOT include other entity-headers. Otherwise, the |
| SHOULD NOT include other entity-headers. If the response is the |  | response MUST include all of the entity-headers that would have been |
| result of an If-Range request that used a weak validator, the |  | returned with a 200 (OK) response to the same request. |
| response MUST NOT include other entity-headers; this prevents |  |  |
| inconsistencies between cached entity-bodies and updated headers. |  |  |
| Otherwise, the response MUST include all of the entity-headers 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 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) responses. |  | MUST NOT cache 206 (Partial Content) responses. |
| 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 |
| range-specifier values in this field overlap the current extent of |  | range-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. (For byte-ranges, this means that the first- |  | request-header field. (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.) |
| skipping to change at page 6, line 23 |  | skipping to change at page 6, line 48 |
| 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 all standard |  | This section defines the syntax and semantics of HTTP/1.1 header |
| HTTP/1.1 header fields. For entity-header fields, both sender and |  | fields related to range requests and partial responses. |
| recipient refer to either the client or the server, depending on who |  |  |
| sends and who receives the entity. |  | 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 the server to indicate |  | The Accept-Ranges response-header field allows the server to indicate |
| its acceptance of range requests for a resource: |  | its acceptance of range requests for a resource: |
| Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges |  | Accept-Ranges = "Accept-Ranges" ":" 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 8, line 48 |
| o The last 500 bytes: |  | o The last 500 bytes: |
| bytes 734-1233/1234 |  | bytes 734-1233/1234 |
| When an HTTP message includes the content of a single range (for |  | When an HTTP message includes the content of a single range (for |
| example, a response to a request for a single range, or to a request |  | example, a response to a request for a single range, or to a request |
| for a set of ranges that overlap without any holes), this content is |  | for a set of ranges that overlap without any holes), this content is |
| transmitted with a Content-Range header, and a Content-Length header |  | transmitted with a Content-Range header, and a Content-Length header |
| showing the number of bytes actually transferred. For example, |  | showing the number of bytes actually transferred. For example, |
| HTTP/1.1 206 Partial content |  | HTTP/1.1 206 Partial Content |
| 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 for a compatibility issue. |  | in Appendix A. See Appendix B.1 for a compatibility issue. |
| A response to a request for a single range MUST NOT be sent using the |  | A response to a request for a single range MUST NOT be sent using the |
| multipart/byteranges media type. A response to a request for |  | multipart/byteranges media type. A response to a request for |
| multiple ranges, whose result is a single range, MAY be sent as a |  | multiple ranges, whose result is a single range, MAY be sent as a |
| multipart/byteranges media type with one part. A client that cannot |  | multipart/byteranges media type with one part. A client that cannot |
| decode a multipart/byteranges message MUST NOT ask for multiple byte- |  | decode a multipart/byteranges message MUST NOT ask for multiple byte- |
| ranges in a single request. |  | ranges in a single request. |
| When a client requests multiple byte-ranges in one request, the |  | When a client requests multiple byte-ranges in one request, the |
| server SHOULD return them in the order that they appeared in the |  | server SHOULD return them in the order that they appeared in the |
| skipping to change at page 9, line 42 |  | skipping to change at page 10, line 19 |
| If the client has no entity tag for an entity, but does have a Last- |  | If the client has no entity tag for an entity, but does have a Last- |
| Modified date, it MAY use that date in an If-Range header. (The |  | Modified date, it MAY use that date in an If-Range header. (The |
| server can distinguish between a valid HTTP-date and any form of |  | server can distinguish between a valid HTTP-date and any form of |
| entity-tag by examining no more than two characters.) The If-Range |  | entity-tag by examining no more than two characters.) The If-Range |
| header SHOULD only be used together with a Range header, and MUST be |  | header SHOULD only be used together with a Range header, and MUST be |
| ignored if the request does not include a Range header, or if the |  | ignored if the request does not include a Range header, or if the |
| server does not support the sub-range operation. |  | server does not support the sub-range operation. |
| If the entity tag given in the If-Range header matches the current |  | If the entity tag given in the If-Range header matches the current |
| entity tag for the entity, then the server SHOULD provide the |  | entity tag for the entity, then the server SHOULD provide the |
| specified sub-range of the entity using a 206 (Partial content) |  | specified sub-range of the entity using a 206 (Partial Content) |
| response. If the entity tag does not match, then the server SHOULD |  | response. If the entity tag does not match, then the server SHOULD |
| return the entire entity using a 200 (OK) response. |  | return the entire entity using a 200 (OK) response. |
| 5.4. Range |  | 5.4. Range |
| 5.4.1. Byte Ranges |  | 5.4.1. Byte Ranges |
| Since all HTTP entities are represented in HTTP messages as sequences |  | Since all HTTP entities are represented in HTTP messages as sequences |
| of bytes, the concept of a byte range is meaningful for any HTTP |  | of bytes, the concept of a byte range is meaningful for any HTTP |
| entity. (However, not all clients and servers need to support byte- |  | entity. (However, not all clients and servers need to support byte- |
| skipping to change at page 12, line 35 |  | skipping to change at page 13, line 14 |
| 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. |  | Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin |
|  |  | Hamilton, Koen Holtman, Shel Kaplan, Paul Leach, Alex Lopez-Ortiz, |
| Based on an XML translation of RFC 2616 by Julian Reschke. |  | Larry Masinter, Jeff Mogul, Lou Montulli, David W. Morris, Luigi |
|  |  | Rizzo, and Bill Weihl. |
| 9. References |  | 9. 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., and T. Berners-Lee, "HTTP/1.1, |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| part 1: URIs, Connections, and Message Parsing", |  | and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, |
| draft-ietf-httpbis-p1-messaging-00 (work in progress), |  | and Message Parsing", draft-ietf-httpbis-p1-messaging-01 |
| December 2007. |  | (work in progress), January 2008. |
|  |  | [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-01 |
|  |  | (work in progress), January 2008. |
| [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1, |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| part 4: Conditional Requests", |  | and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional |
| draft-ietf-httpbis-p4-conditional-00 (work in progress), |  | Requests", draft-ietf-httpbis-p4-conditional-01 (work in |
| December 2007. |  | progress), January 2008. |
|  |  | [Part6] 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 6: Caching", |
|  |  | draft-ietf-httpbis-p6-cache-01 (work in progress), |
|  |  | January 2008. |
| [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 |
|  |  | Requirement Levels", BCP 14, RFC 2119, March 1997. |
|  |  | 9.2. Informative References |
| [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |  | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |
| 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. |
| 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. The media type for this purpose is called "multipart/ |  | body. The media type for this purpose is called "multipart/ |
| skipping to change at page 14, line 28 |  | skipping to change at page 15, line 28 |
| Content-range: bytes 7000-7999/8000 |  | Content-range: bytes 7000-7999/8000 |
| ...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. |  | entity. |
| 2. Although RFC 2046 [RFC2046] permits the boundary string to be |  | 2. Although [RFC2046] permits the boundary string to be quoted, some |
| quoted, some existing implementations handle a quoted boundary |  | existing implementations handle a quoted boundary string |
| 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. Changes from RFC 2068 |  | Appendix B. Compatibility with Previous Versions |
|  |  | B.1. Changes from RFC 2068 |
|  |  | 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 |  | There are situations where a server (especially a proxy) does not |
| know the full length of a response but is capable of serving a |  | know the full length of a response but is capable of serving a |
| byterange request. We therefore need a mechanism to allow byteranges |  | byterange request. We therefore need a mechanism to allow byteranges |
| with a content-range not indicating the full length of the message. |  | with a content-range not indicating the full length of the message. |
| (Section 5.2) |  | (Section 5.2) |
| Range request responses would become very verbose if all meta-data |  | Range request responses would become very verbose if all meta-data |
| were always returned; by allowing the server to only send needed |  | were always returned; by allowing the server to only send needed |
| headers in a 206 response, this problem can be avoided. |  | 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: |  | Fix problem with unsatisfiable range requests; there are two cases: |
| syntactic problems, and range doesn't exist in the document. The 416 |  | syntactic problems, and range doesn't exist in the document. The 416 |
| status code was needed to resolve this ambiguity needed to indicate |  | status code was needed to resolve this ambiguity needed to indicate |
| an error for a byte range request that falls outside of the actual |  | an error for a byte range request that falls outside of the actual |
| contents of a document. (Section 3.2, 5.2) |  | 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 |
|  |  | response. (Section 3.1) |
|  |  | Appendix C. Change Log (to be removed by RFC Editor before publication) |
|  |  | C.1. Since RFC2616 |
|  |  | Extracted relevant partitions from [RFC2616]. |
|  |  | C.2. Since draft-ietf-httpbis-p5-range-00 |
|  |  | Closed issues: |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/18>: "Cache |
|  |  | validators in 206 responses" |
|  |  | (<http://purl.org/NET/http-errata#ifrange206>) |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative |
|  |  | and Informative references" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative |
|  |  | up-to-date references" |
| Index |  | Index |
| 2 |  | 2 |
| 206 Partial Content (status code) 4 |  | 206 Partial Content (status code) 5 |
| 4 |  | 4 |
| 416 Requested Range Not Satisfiable (status code) 5 |  | 416 Requested Range Not Satisfiable (status code) 6 |
| A |  | A |
| Accept-Ranges header 6 |  | Accept-Ranges header 7 |
| C |  | C |
| Content-Range header 7 |  | Content-Range header 7 |
| G |  | G |
| Grammar |  | Grammar |
| Accept-Ranges 6 |  | Accept-Ranges 7 |
| acceptable-ranges 6 |  | acceptable-ranges 7 |
| byte-content-range-spec 7 |  | byte-content-range-spec 7 |
| byte-range-resp-spec 7 |  | byte-range-resp-spec 7 |
| byte-range-set 10 |  | byte-range-set 10 |
| byte-range-spec 10 |  | byte-range-spec 10 |
| byte-ranges-specifier 10 |  | byte-ranges-specifier 10 |
| bytes-unit 4 |  | bytes-unit 5 |
| Content-Range 7 |  | Content-Range 7 |
| content-range-spec 7 |  | content-range-spec 7 |
| first-byte-pos 10 |  | first-byte-pos 10 |
| If-Range 9 |  | If-Range 10 |
| instance-length 7 |  | instance-length 7 |
| last-byte-pos 10 |  | last-byte-pos 10 |
| other-range-unit 4 |  | other-range-unit 5 |
| Range 11 |  | Range 12 |
| range-unit 4 |  | range-unit 5 |
| ranges-specifier 10 |  | ranges-specifier 10 |
| suffix-byte-range-spec 10 |  | suffix-byte-range-spec 11 |
| suffix-length 10 |  | suffix-length 11 |
| H |  | H |
| Headers |  | Headers |
| Accept-Ranges 6 |  | Accept-Ranges 7 |
| Content-Range 7 |  | Content-Range 7 |
| If-Range 9 |  | If-Range 9 |
| Range 9 |  | Range 10 |
| I |  | I |
| If-Range header 9 |  | If-Range header 9 |
| M |  | M |
| Media Type |  | Media Type |
| multipart/byteranges 13 |  | multipart/byteranges 14 |
| multipart/x-byteranges 14 |  | multipart/x-byteranges 15 |
| multipart/byteranges Media Type 13 |  | multipart/byteranges Media Type 14 |
| multipart/x-byteranges Media Type 14 |  | multipart/x-byteranges Media Type 15 |
| R |  | R |
| Range header 9 |  | Range header 10 |
| S |  | S |
| Status Codes |  | Status Codes |
| 206 Partial Content 4 |  | 206 Partial Content 5 |
| 416 Requested Range Not Satisfiable 5 |  | 416 Requested Range Not Satisfiable 6 |
| 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 |
| skipping to change at page 18, line 5 |  | skipping to change at page 19, line 31 |
| World Wide Web Consortium |  | World Wide Web Consortium |
| MIT Computer Science and Artificial Intelligence Laboratory |  | MIT Computer Science and Artificial Intelligence Laboratory |
| The Stata Center, Building 32 |  | The Stata Center, Building 32 |
| 32 Vassar Street |  | 32 Vassar Street |
| Cambridge, MA 02139 |  | Cambridge, MA 02139 |
| USA |  | USA |
| Email: timbl@w3.org |  | Email: timbl@w3.org |
| URI: http://www.w3.org/People/Berners-Lee/ |  | URI: http://www.w3.org/People/Berners-Lee/ |
|  |  | Yves Lafon (editor) |
|  |  | World Wide Web Consortium |
|  |  | W3C / ERCIM |
|  |  | 2004, rte des Lucioles |
|  |  | Sophia-Antipolis, AM 06902 |
|  |  | France |
|  |  | Email: ylafon@w3.org |
|  |  | URI: http://www.raubacapeu.net/people/yves/ |
|  |  | Julian F. Reschke (editor) |
|  |  | greenbytes GmbH |
|  |  | Hafenweg 16 |
|  |  | Muenster, NW 48155 |
|  |  | Germany |
|  |  | Phone: +49 251 2807760 |
|  |  | Fax: +49 251 2807761 |
|  |  | Email: julian.reschke@greenbytes.de |
|  |  | URI: http://greenbytes.de/tech/webdav/ |
| Full Copyright Statement |  | Full Copyright Statement |
| Copyright (C) The IETF Trust (2007). |  | Copyright (C) The IETF Trust (2008). |
| This document is subject to the rights, licenses and restrictions |  | This document is subject to the rights, licenses and restrictions |
| contained in BCP 78, and except as set forth therein, the authors |  | contained in BCP 78, and except as set forth therein, the authors |
| retain all their rights. |  | retain all their rights. |
| This document and the information contained herein are provided on an |  | This document and the information contained herein are provided on an |
| "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS |  | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS |
| OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND |  | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND |
| THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS |  | THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS |
| OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF |  | OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF |
End of changes. 47 change blocks.
| 101 lines changed or deleted |  | 212 lines changed or added |
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/