idnits 2.17.1 draft-ietf-httpbis-p5-range-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 30. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 951. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 962. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 969. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 975. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 17, 2008) is 5793 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-03 == Outdated reference: A later version (-20) exists of draft-ietf-httpbis-p3-payload-03 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-03 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-03 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 4288 (Obsoleted by RFC 6838) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Fielding, Ed. 3 Internet-Draft Day Software 4 Obsoletes: 2616 (if approved) J. Gettys 5 Intended status: Standards Track One Laptop per Child 6 Expires: December 19, 2008 J. Mogul 7 HP 8 H. Frystyk 9 Microsoft 10 L. Masinter 11 Adobe Systems 12 P. Leach 13 Microsoft 14 T. Berners-Lee 15 W3C/MIT 16 Y. Lafon, Ed. 17 W3C 18 J. Reschke, Ed. 19 greenbytes 20 June 17, 2008 22 HTTP/1.1, part 5: Range Requests and Partial Responses 23 draft-ietf-httpbis-p5-range-03 25 Status of this Memo 27 By submitting this Internet-Draft, each author represents that any 28 applicable patent or other IPR claims of which he or she is aware 29 have been or will be disclosed, and any of which he or she becomes 30 aware will be disclosed, in accordance with Section 6 of BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on December 19, 2008. 50 Abstract 52 The Hypertext Transfer Protocol (HTTP) is an application-level 53 protocol for distributed, collaborative, hypermedia information 54 systems. HTTP has been in use by the World Wide Web global 55 information initiative since 1990. This document is Part 5 of the 56 seven-part specification that defines the protocol referred to as 57 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines 58 range-specific requests and the rules for constructing and combining 59 responses to those requests. 61 Editorial Note (To be removed by RFC Editor) 63 Discussion of this draft should take place on the HTTPBIS working 64 group mailing list (ietf-http-wg@w3.org). The current issues list is 65 at and related 66 documents (including fancy diffs) can be found at 67 . 69 The changes in this draft are summarized in Appendix C.4. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. Notational Conventions and Generic Grammar . . . . . . . . . . 4 76 3. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5 78 4.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 5 79 4.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 6 80 5. Combining Byte Ranges . . . . . . . . . . . . . . . . . . . . 6 81 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 7 82 6.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7 83 6.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 8 84 6.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 6.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 10 86 6.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 10 87 6.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 12 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 89 7.1. Message Header Registration . . . . . . . . . . . . . . . 13 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 91 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 94 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 95 Appendix A. Internet Media Type multipart/byteranges . . . . . . 15 96 Appendix B. Compatibility with Previous Versions . . . . . . . . 17 97 B.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 17 98 B.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 17 99 Appendix C. Change Log (to be removed by RFC Editor before 100 publication) . . . . . . . . . . . . . . . . . . . . 17 101 C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 17 102 C.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 18 103 C.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 18 104 C.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 18 105 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 107 Intellectual Property and Copyright Statements . . . . . . . . . . 23 109 1. Introduction 111 HTTP clients often encounter interrupted data transfers as a result 112 of cancelled requests or dropped connections. When a cache has 113 stored a partial representation, it is desirable to request the 114 remainder of that representation in a subsequent request rather than 115 transfer the entire representation. There are also a number of Web 116 applications that benefit from being able to request only a subset of 117 a larger representation, such as a single page of a very large 118 document or only part of an image to be rendered by a device with 119 limited local storage. 121 This document defines HTTP/1.1 range requests, partial responses, and 122 the multipart/byteranges media type. The protocol for range requests 123 is an OPTIONAL feature of HTTP, designed so resources or recipients 124 that do not implement this feature can respond as if it is a normal 125 GET request without impacting interoperability. Partial responses 126 are indicated by a distinct status code to not be mistaken for full 127 responses by intermediate caches that might not implement the 128 feature. 130 Although the HTTP range request mechanism is designed to allow for 131 extensible range types, this specification only defines requests for 132 byte ranges. 134 1.1. Requirements 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. 140 An implementation is not compliant if it fails to satisfy one or more 141 of the MUST or REQUIRED level requirements for the protocols it 142 implements. An implementation that satisfies all the MUST or 143 REQUIRED level and all the SHOULD level requirements for its 144 protocols is said to be "unconditionally compliant"; one that 145 satisfies all the MUST level requirements but not all the SHOULD 146 level requirements for its protocols is said to be "conditionally 147 compliant." 149 2. Notational Conventions and Generic Grammar 151 This specification uses the ABNF syntax defined in Section 2.1 of 152 [Part1] and the core rules defined in Section 2.2 of [Part1]: 153 [[abnf.dep: ABNF syntax and basic rules will be adopted from RFC 154 5234, see .]] 155 DIGIT = 156 SP = 158 token = 160 The ABNF rules below are defined in other parts: 162 HTTP-date = 164 entity-tag = 166 3. Range Units 168 HTTP/1.1 allows a client to request that only part (a range of) the 169 response entity be included within the response. HTTP/1.1 uses range 170 units in the Range (Section 6.4) and Content-Range (Section 6.2) 171 header fields. An entity can be broken down into subranges according 172 to various structural units. 174 range-unit = bytes-unit | other-range-unit 175 bytes-unit = "bytes" 176 other-range-unit = token 178 The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 179 implementations MAY ignore ranges specified using other units. 181 HTTP/1.1 has been designed to allow implementations of applications 182 that do not depend on knowledge of ranges. 184 4. Status Code Definitions 186 4.1. 206 Partial Content 188 The server has fulfilled the partial GET request for the resource. 189 The request MUST have included a Range header field (Section 6.4) 190 indicating the desired range, and MAY have included an If-Range 191 header field (Section 6.3) to make the request conditional. 193 The response MUST include the following header fields: 195 o Either a Content-Range header field (Section 6.2) indicating the 196 range included with this response, or a multipart/byteranges 197 Content-Type including Content-Range fields for each part. If a 198 Content-Length header field is present in the response, its value 199 MUST match the actual number of OCTETs transmitted in the message- 200 body. 202 o Date 204 o ETag and/or Content-Location, if the header would have been sent 205 in a 200 response to the same request 207 o Expires, Cache-Control, and/or Vary, if the field-value might 208 differ from that sent in any previous response for the same 209 variant 211 If the 206 response is the result of an If-Range request, the 212 response SHOULD NOT include other entity-headers. Otherwise, the 213 response MUST include all of the entity-headers that would have been 214 returned with a 200 (OK) response to the same request. 216 A cache MUST NOT combine a 206 response with other previously cached 217 content if the ETag or Last-Modified headers do not match exactly, 218 see Section 5. 220 A cache that does not support the Range and Content-Range headers 221 MUST NOT cache 206 (Partial Content) responses. 223 4.2. 416 Requested Range Not Satisfiable 225 A server SHOULD return a response with this status code if a request 226 included a Range request-header field (Section 6.4), and none of the 227 range-specifier values in this field overlap the current extent of 228 the selected resource, and the request did not include an If-Range 229 request-header field. (For byte-ranges, this means that the first- 230 byte-pos of all of the byte-range-spec values were greater than the 231 current length of the selected resource.) 233 When this status code is returned for a byte-range request, the 234 response SHOULD include a Content-Range entity-header field 235 specifying the current length of the selected resource (see 236 Section 6.2). This response MUST NOT use the multipart/byteranges 237 content-type. 239 5. Combining Byte Ranges 241 A response might transfer only a subrange of the bytes of an entity- 242 body, either because the request included one or more Range 243 specifications, or because a connection was broken prematurely. 244 After several such transfers, a cache might have received several 245 ranges of the same entity-body. 247 If a cache has a stored non-empty set of subranges for an entity, and 248 an incoming response transfers another subrange, the cache MAY 249 combine the new subrange with the existing set if both the following 250 conditions are met: 252 o Both the incoming response and the cache entry have a cache 253 validator. 255 o The two cache validators match using the strong comparison 256 function (see Section 5 of [Part4]). 258 If either requirement is not met, the cache MUST use only the most 259 recent partial response (based on the Date values transmitted with 260 every response, and using the incoming response if these values are 261 equal or missing), and MUST discard the other partial information. 263 6. Header Field Definitions 265 This section defines the syntax and semantics of HTTP/1.1 header 266 fields related to range requests and partial responses. 268 For entity-header fields, both sender and recipient refer to either 269 the client or the server, depending on who sends and who receives the 270 entity. 272 6.1. Accept-Ranges 274 The Accept-Ranges response-header field allows the server to indicate 275 its acceptance of range requests for a resource: 277 Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges 278 acceptable-ranges = 1#range-unit | "none" 280 Origin servers that accept byte-range requests MAY send 282 Accept-Ranges: bytes 284 but are not required to do so. Clients MAY generate byte-range 285 requests without having received this header for the resource 286 involved. Range units are defined in Section 3. 288 Servers that do not accept any kind of range request for a resource 289 MAY send 291 Accept-Ranges: none 293 to advise the client not to attempt a range request. 295 6.2. Content-Range 297 The Content-Range entity-header is sent with a partial entity-body to 298 specify where in the full entity-body the partial body should be 299 applied. Range units are defined in Section 3. 301 Content-Range = "Content-Range" ":" content-range-spec 303 content-range-spec = byte-content-range-spec 304 byte-content-range-spec = bytes-unit SP 305 byte-range-resp-spec "/" 306 ( instance-length | "*" ) 308 byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) 309 | "*" 310 instance-length = 1*DIGIT 312 The header SHOULD indicate the total length of the full entity-body, 313 unless this length is unknown or difficult to determine. The 314 asterisk "*" character means that the instance-length is unknown at 315 the time when the response was generated. 317 Unlike byte-ranges-specifier values (see Section 6.4.1), a byte- 318 range-resp-spec MUST only specify one range, and MUST contain 319 absolute byte positions for both the first and last byte of the 320 range. 322 A byte-content-range-spec with a byte-range-resp-spec whose last- 323 byte-pos value is less than its first-byte-pos value, or whose 324 instance-length value is less than or equal to its last-byte-pos 325 value, is invalid. The recipient of an invalid byte-content-range- 326 spec MUST ignore it and any content transferred along with it. 328 A server sending a response with status code 416 (Requested range not 329 satisfiable) SHOULD include a Content-Range field with a byte-range- 330 resp-spec of "*". The instance-length specifies the current length 331 of the selected resource. A response with status code 206 (Partial 332 Content) MUST NOT include a Content-Range field with a byte-range- 333 resp-spec of "*". 335 Examples of byte-content-range-spec values, assuming that the entity 336 contains a total of 1234 bytes: 338 o The first 500 bytes: 340 bytes 0-499/1234 342 o The second 500 bytes: 344 bytes 500-999/1234 346 o All except for the first 500 bytes: 348 bytes 500-1233/1234 350 o The last 500 bytes: 352 bytes 734-1233/1234 354 When an HTTP message includes the content of a single range (for 355 example, a response to a request for a single range, or to a request 356 for a set of ranges that overlap without any holes), this content is 357 transmitted with a Content-Range header, and a Content-Length header 358 showing the number of bytes actually transferred. For example, 360 HTTP/1.1 206 Partial Content 361 Date: Wed, 15 Nov 1995 06:25:24 GMT 362 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 363 Content-Range: bytes 21010-47021/47022 364 Content-Length: 26012 365 Content-Type: image/gif 367 When an HTTP message includes the content of multiple ranges (for 368 example, a response to a request for multiple non-overlapping 369 ranges), these are transmitted as a multipart message. The multipart 370 media type used for this purpose is "multipart/byteranges" as defined 371 in Appendix A. See Appendix B.1 for a compatibility issue. 373 A response to a request for a single range MUST NOT be sent using the 374 multipart/byteranges media type. A response to a request for 375 multiple ranges, whose result is a single range, MAY be sent as a 376 multipart/byteranges media type with one part. A client that cannot 377 decode a multipart/byteranges message MUST NOT ask for multiple byte- 378 ranges in a single request. 380 When a client requests multiple byte-ranges in one request, the 381 server SHOULD return them in the order that they appeared in the 382 request. 384 If the server ignores a byte-range-spec because it is syntactically 385 invalid, the server SHOULD treat the request as if the invalid Range 386 header field did not exist. (Normally, this means return a 200 387 response containing the full entity). 389 If the server receives a request (other than one including an If- 390 Range request-header field) with an unsatisfiable Range request- 391 header field (that is, all of whose byte-range-spec values have a 392 first-byte-pos value greater than the current length of the selected 393 resource), it SHOULD return a response code of 416 (Requested range 394 not satisfiable) (Section 4.2). 396 Note: clients cannot depend on servers to send a 416 (Requested 397 range not satisfiable) response instead of a 200 (OK) response for 398 an unsatisfiable Range request-header, since not all servers 399 implement this request-header. 401 6.3. If-Range 403 If a client has a partial copy of an entity in its cache, and wishes 404 to have an up-to-date copy of the entire entity in its cache, it 405 could use the Range request-header with a conditional GET (using 406 either or both of If-Unmodified-Since and If-Match.) However, if the 407 condition fails because the entity has been modified, the client 408 would then have to make a second request to obtain the entire current 409 entity-body. 411 The If-Range header allows a client to "short-circuit" the second 412 request. Informally, its meaning is `if the entity is unchanged, 413 send me the part(s) that I am missing; otherwise, send me the entire 414 new entity'. 416 If-Range = "If-Range" ":" ( entity-tag | HTTP-date ) 418 If the client has no entity tag for an entity, but does have a Last- 419 Modified date, it MAY use that date in an If-Range header. (The 420 server can distinguish between a valid HTTP-date and any form of 421 entity-tag by examining no more than two characters.) The If-Range 422 header SHOULD only be used together with a Range header, and MUST be 423 ignored if the request does not include a Range header, or if the 424 server does not support the sub-range operation. 426 If the entity tag given in the If-Range header matches the current 427 entity tag for the entity, then the server SHOULD provide the 428 specified sub-range of the entity using a 206 (Partial Content) 429 response. If the entity tag does not match, then the server SHOULD 430 return the entire entity using a 200 (OK) response. 432 6.4. Range 434 6.4.1. Byte Ranges 436 Since all HTTP entities are represented in HTTP messages as sequences 437 of bytes, the concept of a byte range is meaningful for any HTTP 438 entity. (However, not all clients and servers need to support byte- 439 range operations.) 441 Byte range specifications in HTTP apply to the sequence of bytes in 442 the entity-body (not necessarily the same as the message-body). 444 A byte range operation MAY specify a single range of bytes, or a set 445 of ranges within a single entity. 447 ranges-specifier = byte-ranges-specifier 448 byte-ranges-specifier = bytes-unit "=" byte-range-set 449 byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec ) 450 byte-range-spec = first-byte-pos "-" [last-byte-pos] 451 first-byte-pos = 1*DIGIT 452 last-byte-pos = 1*DIGIT 454 The first-byte-pos value in a byte-range-spec gives the byte-offset 455 of the first byte in a range. The last-byte-pos value gives the 456 byte-offset of the last byte in the range; that is, the byte 457 positions specified are inclusive. Byte offsets start at zero. 459 If the last-byte-pos value is present, it MUST be greater than or 460 equal to the first-byte-pos in that byte-range-spec, or the byte- 461 range-spec is syntactically invalid. The recipient of a byte-range- 462 set that includes one or more syntactically invalid byte-range-spec 463 values MUST ignore the header field that includes that byte-range- 464 set. 466 If the last-byte-pos value is absent, or if the value is greater than 467 or equal to the current length of the entity-body, last-byte-pos is 468 taken to be equal to one less than the current length of the entity- 469 body in bytes. 471 By its choice of last-byte-pos, a client can limit the number of 472 bytes retrieved without knowing the size of the entity. 474 suffix-byte-range-spec = "-" suffix-length 475 suffix-length = 1*DIGIT 477 A suffix-byte-range-spec is used to specify the suffix of the entity- 478 body, of a length given by the suffix-length value. (That is, this 479 form specifies the last N bytes of an entity-body.) If the entity is 480 shorter than the specified suffix-length, the entire entity-body is 481 used. 483 If a syntactically valid byte-range-set includes at least one byte- 484 range-spec whose first-byte-pos is less than the current length of 485 the entity-body, or at least one suffix-byte-range-spec with a non- 486 zero suffix-length, then the byte-range-set is satisfiable. 487 Otherwise, the byte-range-set is unsatisfiable. If the byte-range- 488 set is unsatisfiable, the server SHOULD return a response with a 489 status of 416 (Requested range not satisfiable). Otherwise, the 490 server SHOULD return a response with a status of 206 (Partial 491 Content) containing the satisfiable ranges of the entity-body. 493 Examples of byte-ranges-specifier values (assuming an entity-body of 494 length 10000): 496 o The first 500 bytes (byte offsets 0-499, inclusive): bytes=0-499 498 o The second 500 bytes (byte offsets 500-999, inclusive): bytes=500- 499 999 501 o The final 500 bytes (byte offsets 9500-9999, inclusive): bytes=- 502 500 504 o Or bytes=9500- 506 o The first and last bytes only (bytes 0 and 9999): bytes=0-0,-1 508 o Several legal but not canonical specifications of the second 500 509 bytes (byte offsets 500-999, inclusive): 510 bytes=500-600,601-999 511 bytes=500-700,601-999 513 6.4.2. Range Retrieval Requests 515 HTTP retrieval requests using conditional or unconditional GET 516 methods MAY request one or more sub-ranges of the entity, instead of 517 the entire entity, using the Range request header, which applies to 518 the entity returned as the result of the request: 520 Range = "Range" ":" ranges-specifier 522 A server MAY ignore the Range header. However, HTTP/1.1 origin 523 servers and intermediate caches ought to support byte ranges when 524 possible, since Range supports efficient recovery from partially 525 failed transfers, and supports efficient partial retrieval of large 526 entities. 528 If the server supports the Range header and the specified range or 529 ranges are appropriate for the entity: 531 o The presence of a Range header in an unconditional GET modifies 532 what is returned if the GET is otherwise successful. In other 533 words, the response carries a status code of 206 (Partial Content) 534 instead of 200 (OK). 536 o The presence of a Range header in a conditional GET (a request 537 using one or both of If-Modified-Since and If-None-Match, or one 538 or both of If-Unmodified-Since and If-Match) modifies what is 539 returned if the GET is otherwise successful and the condition is 540 true. It does not affect the 304 (Not Modified) response returned 541 if the conditional is false. 543 In some cases, it might be more appropriate to use the If-Range 544 header (see Section 6.3) in addition to the Range header. 546 If a proxy that supports ranges receives a Range request, forwards 547 the request to an inbound server, and receives an entire entity in 548 reply, it SHOULD only return the requested range to its client. It 549 SHOULD store the entire received response in its cache if that is 550 consistent with its cache allocation policies. 552 7. IANA Considerations 554 7.1. Message Header Registration 556 The Message Header Registry located at should be 558 updated with the permanent registrations below (see [RFC3864]): 560 +-------------------+----------+----------+-------------+ 561 | Header Field Name | Protocol | Status | Reference | 562 +-------------------+----------+----------+-------------+ 563 | Accept-Ranges | http | standard | Section 6.1 | 564 | Content-Range | http | standard | Section 6.2 | 565 | If-Range | http | standard | Section 6.3 | 566 | Range | http | standard | Section 6.4 | 567 +-------------------+----------+----------+-------------+ 569 The change controller is: "IETF (iesg@ietf.org) - Internet 570 Engineering Task Force". 572 8. Security Considerations 574 No additional security considerations have been identified beyond 575 those applicable to HTTP in general [Part1]. 577 9. Acknowledgments 579 Most of the specification of ranges is based on work originally done 580 by Ari Luotonen and John Franks, with additional input from Steve 581 Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin 582 Hamilton, Koen Holtman, Shel Kaplan, Paul Leach, Alex Lopez-Ortiz, 583 Larry Masinter, Jeff Mogul, Lou Montulli, David W. Morris, Luigi 584 Rizzo, and Bill Weihl. 586 10. References 588 10.1. Normative References 590 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 591 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 592 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, 593 and Message Parsing", draft-ietf-httpbis-p1-messaging-03 594 (work in progress), June 2008. 596 [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 597 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 598 and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload 599 and Content Negotiation", draft-ietf-httpbis-p3-payload-03 600 (work in progress), June 2008. 602 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 603 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 604 and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional 605 Requests", draft-ietf-httpbis-p4-conditional-03 (work in 606 progress), June 2008. 608 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 609 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 610 and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", 611 draft-ietf-httpbis-p6-cache-03 (work in progress), 612 June 2008. 614 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 615 Extensions (MIME) Part Two: Media Types", RFC 2046, 616 November 1996. 618 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 619 Requirement Levels", BCP 14, RFC 2119, March 1997. 621 10.2. Informative References 623 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 624 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 625 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 627 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 628 Procedures for Message Header Fields", BCP 90, RFC 3864, 629 September 2004. 631 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 632 Registration Procedures", BCP 13, RFC 4288, December 2005. 634 Appendix A. Internet Media Type multipart/byteranges 636 When an HTTP 206 (Partial Content) response message includes the 637 content of multiple ranges (a response to a request for multiple non- 638 overlapping ranges), these are transmitted as a multipart message- 639 body [RFC2046]. The media type for this purpose is called 640 "multipart/byteranges". The following is to be registered with IANA 641 [RFC4288]. 643 The multipart/byteranges media type includes two or more parts, each 644 with its own Content-Type and Content-Range fields. The required 645 boundary parameter specifies the boundary string used to separate 646 each body-part. 648 Type name: multipart 650 Subtype name: byteranges 652 Required parameters: boundary 654 Optional parameters: none 656 Encoding considerations: only "7bit", "8bit", or "binary" are 657 permitted 659 Security considerations: none 661 Interoperability considerations: none 663 Published specification: This specification (see Appendix A). 665 Applications that use this media type: 667 Additional information: 669 Magic number(s): none 671 File extension(s): none 673 Macintosh file type code(s): none 675 Person and email address to contact for further information: See 676 Authors Section. 678 Intended usage: COMMON 680 Restrictions on usage: none 682 Author/Change controller: IESG 684 For example: 686 HTTP/1.1 206 Partial Content 687 Date: Wed, 15 Nov 1995 06:25:24 GMT 688 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 689 Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES 691 --THIS_STRING_SEPARATES 692 Content-type: application/pdf 693 Content-range: bytes 500-999/8000 695 ...the first range... 696 --THIS_STRING_SEPARATES 697 Content-type: application/pdf 698 Content-range: bytes 7000-7999/8000 700 ...the second range 701 --THIS_STRING_SEPARATES-- 703 Notes: 705 1. Additional CRLFs may precede the first boundary string in the 706 entity. 708 2. Although [RFC2046] permits the boundary string to be quoted, some 709 existing implementations handle a quoted boundary string 710 incorrectly. 712 3. A number of browsers and servers were coded to an early draft of 713 the byteranges specification to use a media type of multipart/ 714 x-byteranges, which is almost, but not quite compatible with the 715 version documented in HTTP/1.1. 717 Appendix B. Compatibility with Previous Versions 719 B.1. Changes from RFC 2068 721 Transfer-coding and message lengths all interact in ways that 722 required fixing exactly when chunked encoding is used (to allow for 723 transfer encoding that may not be self delimiting); it was important 724 to straighten out exactly how message lengths are computed. 725 (Section 6.2, see also [Part1], [Part3] and [Part6]) 727 There are situations where a server (especially a proxy) does not 728 know the full length of a response but is capable of serving a 729 byterange request. We therefore need a mechanism to allow byteranges 730 with a content-range not indicating the full length of the message. 731 (Section 6.2) 733 Range request responses would become very verbose if all meta-data 734 were always returned; by allowing the server to only send needed 735 headers in a 206 response, this problem can be avoided. (Section 4.1 736 and 6.3) 738 Fix problem with unsatisfiable range requests; there are two cases: 739 syntactic problems, and range doesn't exist in the document. The 416 740 status code was needed to resolve this ambiguity needed to indicate 741 an error for a byte range request that falls outside of the actual 742 contents of a document. (Section 4.2, 6.2) 744 B.2. Changes from RFC 2616 746 Clarify that it is not ok to use a weak cache validator in a 206 747 response. (Section 4.1) 749 Appendix C. Change Log (to be removed by RFC Editor before publication) 751 C.1. Since RFC2616 753 Extracted relevant partitions from [RFC2616]. 755 C.2. Since draft-ietf-httpbis-p5-range-00 757 Closed issues: 759 o : "Cache 760 validators in 206 responses" 761 () 763 o : "Normative 764 and Informative references" 766 o : "Normative 767 up-to-date references" 769 C.3. Since draft-ietf-httpbis-p5-range-01 771 Closed issues: 773 o : "Updating 774 to RFC4288" 776 Ongoing work on ABNF conversion 777 (): 779 o Add explicit references to BNF syntax and rules imported from 780 other parts of the specification. 782 C.4. Since draft-ietf-httpbis-p5-range-02 784 Ongoing work on IANA Message Header Registration 785 (): 787 o Reference RFC 3984, and update header registrations for headers 788 defined in this document. 790 Index 792 2 793 206 Partial Content (status code) 5 795 4 796 416 Requested Range Not Satisfiable (status code) 6 798 A 799 Accept-Ranges header 7 801 C 802 Content-Range header 8 804 G 805 Grammar 806 Accept-Ranges 7 807 acceptable-ranges 7 808 byte-content-range-spec 8 809 byte-range-resp-spec 8 810 byte-range-set 11 811 byte-range-spec 11 812 byte-ranges-specifier 11 813 bytes-unit 5 814 Content-Range 8 815 content-range-spec 8 816 first-byte-pos 11 817 If-Range 10 818 instance-length 8 819 last-byte-pos 11 820 other-range-unit 5 821 Range 12 822 range-unit 5 823 ranges-specifier 11 824 suffix-byte-range-spec 11 825 suffix-length 11 827 H 828 Headers 829 Accept-Ranges 7 830 Content-Range 8 831 If-Range 10 832 Range 10 834 I 835 If-Range header 10 837 M 838 Media Type 839 multipart/byteranges 15 840 multipart/x-byteranges 17 841 multipart/byteranges Media Type 15 842 multipart/x-byteranges Media Type 17 844 R 845 Range header 10 847 S 848 Status Codes 849 206 Partial Content 5 850 416 Requested Range Not Satisfiable 6 852 Authors' Addresses 854 Roy T. Fielding (editor) 855 Day Software 856 23 Corporate Plaza DR, Suite 280 857 Newport Beach, CA 92660 858 USA 860 Phone: +1-949-706-5300 861 Fax: +1-949-706-5305 862 Email: fielding@gbiv.com 863 URI: http://roy.gbiv.com/ 865 Jim Gettys 866 One Laptop per Child 867 21 Oak Knoll Road 868 Carlisle, MA 01741 869 USA 871 Email: jg@laptop.org 872 URI: http://www.laptop.org/ 874 Jeffrey C. Mogul 875 Hewlett-Packard Company 876 HP Labs, Large Scale Systems Group 877 1501 Page Mill Road, MS 1177 878 Palo Alto, CA 94304 879 USA 881 Email: JeffMogul@acm.org 883 Henrik Frystyk Nielsen 884 Microsoft Corporation 885 1 Microsoft Way 886 Redmond, WA 98052 887 USA 889 Email: henrikn@microsoft.com 890 Larry Masinter 891 Adobe Systems, Incorporated 892 345 Park Ave 893 San Jose, CA 95110 894 USA 896 Email: LMM@acm.org 897 URI: http://larry.masinter.net/ 899 Paul J. Leach 900 Microsoft Corporation 901 1 Microsoft Way 902 Redmond, WA 98052 904 Email: paulle@microsoft.com 906 Tim Berners-Lee 907 World Wide Web Consortium 908 MIT Computer Science and Artificial Intelligence Laboratory 909 The Stata Center, Building 32 910 32 Vassar Street 911 Cambridge, MA 02139 912 USA 914 Email: timbl@w3.org 915 URI: http://www.w3.org/People/Berners-Lee/ 917 Yves Lafon (editor) 918 World Wide Web Consortium 919 W3C / ERCIM 920 2004, rte des Lucioles 921 Sophia-Antipolis, AM 06902 922 France 924 Email: ylafon@w3.org 925 URI: http://www.raubacapeu.net/people/yves/ 926 Julian F. Reschke (editor) 927 greenbytes GmbH 928 Hafenweg 16 929 Muenster, NW 48155 930 Germany 932 Phone: +49 251 2807760 933 Fax: +49 251 2807761 934 Email: julian.reschke@greenbytes.de 935 URI: http://greenbytes.de/tech/webdav/ 937 Full Copyright Statement 939 Copyright (C) The IETF Trust (2008). 941 This document is subject to the rights, licenses and restrictions 942 contained in BCP 78, and except as set forth therein, the authors 943 retain all their rights. 945 This document and the information contained herein are provided on an 946 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 947 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 948 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 949 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 950 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 951 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 953 Intellectual Property 955 The IETF takes no position regarding the validity or scope of any 956 Intellectual Property Rights or other rights that might be claimed to 957 pertain to the implementation or use of the technology described in 958 this document or the extent to which any license under such rights 959 might or might not be available; nor does it represent that it has 960 made any independent effort to identify any such rights. Information 961 on the procedures with respect to rights in RFC documents can be 962 found in BCP 78 and BCP 79. 964 Copies of IPR disclosures made to the IETF Secretariat and any 965 assurances of licenses to be made available, or the result of an 966 attempt made to obtain a general license or permission for the use of 967 such proprietary rights by implementers or users of this 968 specification can be obtained from the IETF on-line IPR repository at 969 http://www.ietf.org/ipr. 971 The IETF invites any interested party to bring to its attention any 972 copyrights, patents or patent applications, or other proprietary 973 rights that may cover technology that may be required to implement 974 this standard. Please address the information to the IETF at 975 ietf-ipr@ietf.org.