idnits 2.17.1 draft-ietf-httpbis-p5-range-04.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 955. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 966. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 973. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 979. 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 (August 29, 2008) is 5690 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-04 == Outdated reference: A later version (-20) exists of draft-ietf-httpbis-p3-payload-04 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-04 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-04 -- 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: March 2, 2009 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 August 29, 2008 22 HTTP/1.1, part 5: Range Requests and Partial Responses 23 draft-ietf-httpbis-p5-range-04 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 March 2, 2009. 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 C.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 18 106 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 108 Intellectual Property and Copyright Statements . . . . . . . . . . 23 110 1. Introduction 112 HTTP clients often encounter interrupted data transfers as a result 113 of cancelled requests or dropped connections. When a cache has 114 stored a partial representation, it is desirable to request the 115 remainder of that representation in a subsequent request rather than 116 transfer the entire representation. There are also a number of Web 117 applications that benefit from being able to request only a subset of 118 a larger representation, such as a single page of a very large 119 document or only part of an image to be rendered by a device with 120 limited local storage. 122 This document defines HTTP/1.1 range requests, partial responses, and 123 the multipart/byteranges media type. The protocol for range requests 124 is an OPTIONAL feature of HTTP, designed so resources or recipients 125 that do not implement this feature can respond as if it is a normal 126 GET request without impacting interoperability. Partial responses 127 are indicated by a distinct status code to not be mistaken for full 128 responses by intermediate caches that might not implement the 129 feature. 131 Although the HTTP range request mechanism is designed to allow for 132 extensible range types, this specification only defines requests for 133 byte ranges. 135 1.1. Requirements 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 An implementation is not compliant if it fails to satisfy one or more 142 of the MUST or REQUIRED level requirements for the protocols it 143 implements. An implementation that satisfies all the MUST or 144 REQUIRED level and all the SHOULD level requirements for its 145 protocols is said to be "unconditionally compliant"; one that 146 satisfies all the MUST level requirements but not all the SHOULD 147 level requirements for its protocols is said to be "conditionally 148 compliant." 150 2. Notational Conventions and Generic Grammar 152 This specification uses the ABNF syntax defined in Section 2.1 of 153 [Part1] and the core rules defined in Section 2.2 of [Part1]: 154 [[abnf.dep: ABNF syntax and basic rules will be adopted from RFC 155 5234, see .]] 156 DIGIT = 157 SP = 159 token = 161 The ABNF rules below are defined in other parts: 163 HTTP-date = 165 entity-tag = 167 3. Range Units 169 HTTP/1.1 allows a client to request that only part (a range of) the 170 response entity be included within the response. HTTP/1.1 uses range 171 units in the Range (Section 6.4) and Content-Range (Section 6.2) 172 header fields. An entity can be broken down into subranges according 173 to various structural units. 175 range-unit = bytes-unit | other-range-unit 176 bytes-unit = "bytes" 177 other-range-unit = token 179 The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 180 implementations MAY ignore ranges specified using other units. 182 HTTP/1.1 has been designed to allow implementations of applications 183 that do not depend on knowledge of ranges. 185 4. Status Code Definitions 187 4.1. 206 Partial Content 189 The server has fulfilled the partial GET request for the resource. 190 The request MUST have included a Range header field (Section 6.4) 191 indicating the desired range, and MAY have included an If-Range 192 header field (Section 6.3) to make the request conditional. 194 The response MUST include the following header fields: 196 o Either a Content-Range header field (Section 6.2) indicating the 197 range included with this response, or a multipart/byteranges 198 Content-Type including Content-Range fields for each part. If a 199 Content-Length header field is present in the response, its value 200 MUST match the actual number of OCTETs transmitted in the message- 201 body. 203 o Date 205 o ETag and/or Content-Location, if the header would have been sent 206 in a 200 response to the same request 208 o Expires, Cache-Control, and/or Vary, if the field-value might 209 differ from that sent in any previous response for the same 210 variant 212 If the 206 response is the result of an If-Range request, the 213 response SHOULD NOT include other entity-headers. Otherwise, the 214 response MUST include all of the entity-headers that would have been 215 returned with a 200 (OK) response to the same request. 217 A cache MUST NOT combine a 206 response with other previously cached 218 content if the ETag or Last-Modified headers do not match exactly, 219 see Section 5. 221 A cache that does not support the Range and Content-Range headers 222 MUST NOT cache 206 (Partial Content) responses. 224 4.2. 416 Requested Range Not Satisfiable 226 A server SHOULD return a response with this status code if a request 227 included a Range request-header field (Section 6.4), and none of the 228 range-specifier values in this field overlap the current extent of 229 the selected resource, and the request did not include an If-Range 230 request-header field. (For byte-ranges, this means that the first- 231 byte-pos of all of the byte-range-spec values were greater than the 232 current length of the selected resource.) 234 When this status code is returned for a byte-range request, the 235 response SHOULD include a Content-Range entity-header field 236 specifying the current length of the selected resource (see 237 Section 6.2). This response MUST NOT use the multipart/byteranges 238 content-type. 240 5. Combining Byte Ranges 242 A response might transfer only a subrange of the bytes of an entity- 243 body, either because the request included one or more Range 244 specifications, or because a connection was broken prematurely. 245 After several such transfers, a cache might have received several 246 ranges of the same entity-body. 248 If a cache has a stored non-empty set of subranges for an entity, and 249 an incoming response transfers another subrange, the cache MAY 250 combine the new subrange with the existing set if both the following 251 conditions are met: 253 o Both the incoming response and the cache entry have a cache 254 validator. 256 o The two cache validators match using the strong comparison 257 function (see Section 5 of [Part4]). 259 If either requirement is not met, the cache MUST use only the most 260 recent partial response (based on the Date values transmitted with 261 every response, and using the incoming response if these values are 262 equal or missing), and MUST discard the other partial information. 264 6. Header Field Definitions 266 This section defines the syntax and semantics of HTTP/1.1 header 267 fields related to range requests and partial responses. 269 For entity-header fields, both sender and recipient refer to either 270 the client or the server, depending on who sends and who receives the 271 entity. 273 6.1. Accept-Ranges 275 The Accept-Ranges response-header field allows the server to indicate 276 its acceptance of range requests for a resource: 278 Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges 279 acceptable-ranges = 1#range-unit | "none" 281 Origin servers that accept byte-range requests MAY send 283 Accept-Ranges: bytes 285 but are not required to do so. Clients MAY generate byte-range 286 requests without having received this header for the resource 287 involved. Range units are defined in Section 3. 289 Servers that do not accept any kind of range request for a resource 290 MAY send 292 Accept-Ranges: none 294 to advise the client not to attempt a range request. 296 6.2. Content-Range 298 The Content-Range entity-header is sent with a partial entity-body to 299 specify where in the full entity-body the partial body should be 300 applied. Range units are defined in Section 3. 302 Content-Range = "Content-Range" ":" content-range-spec 304 content-range-spec = byte-content-range-spec 305 byte-content-range-spec = bytes-unit SP 306 byte-range-resp-spec "/" 307 ( instance-length | "*" ) 309 byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) 310 | "*" 312 instance-length = 1*DIGIT 314 The header SHOULD indicate the total length of the full entity-body, 315 unless this length is unknown or difficult to determine. The 316 asterisk "*" character means that the instance-length is unknown at 317 the time when the response was generated. 319 Unlike byte-ranges-specifier values (see Section 6.4.1), a byte- 320 range-resp-spec MUST only specify one range, and MUST contain 321 absolute byte positions for both the first and last byte of the 322 range. 324 A byte-content-range-spec with a byte-range-resp-spec whose last- 325 byte-pos value is less than its first-byte-pos value, or whose 326 instance-length value is less than or equal to its last-byte-pos 327 value, is invalid. The recipient of an invalid byte-content-range- 328 spec MUST ignore it and any content transferred along with it. 330 A server sending a response with status code 416 (Requested range not 331 satisfiable) SHOULD include a Content-Range field with a byte-range- 332 resp-spec of "*". The instance-length specifies the current length 333 of the selected resource. A response with status code 206 (Partial 334 Content) MUST NOT include a Content-Range field with a byte-range- 335 resp-spec of "*". 337 Examples of byte-content-range-spec values, assuming that the entity 338 contains a total of 1234 bytes: 340 o The first 500 bytes: 342 bytes 0-499/1234 344 o The second 500 bytes: 346 bytes 500-999/1234 348 o All except for the first 500 bytes: 350 bytes 500-1233/1234 352 o The last 500 bytes: 354 bytes 734-1233/1234 356 When an HTTP message includes the content of a single range (for 357 example, a response to a request for a single range, or to a request 358 for a set of ranges that overlap without any holes), this content is 359 transmitted with a Content-Range header, and a Content-Length header 360 showing the number of bytes actually transferred. For example, 362 HTTP/1.1 206 Partial Content 363 Date: Wed, 15 Nov 1995 06:25:24 GMT 364 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 365 Content-Range: bytes 21010-47021/47022 366 Content-Length: 26012 367 Content-Type: image/gif 369 When an HTTP message includes the content of multiple ranges (for 370 example, a response to a request for multiple non-overlapping 371 ranges), these are transmitted as a multipart message. The multipart 372 media type used for this purpose is "multipart/byteranges" as defined 373 in Appendix A. See Appendix B.1 for a compatibility issue. 375 A response to a request for a single range MUST NOT be sent using the 376 multipart/byteranges media type. A response to a request for 377 multiple ranges, whose result is a single range, MAY be sent as a 378 multipart/byteranges media type with one part. A client that cannot 379 decode a multipart/byteranges message MUST NOT ask for multiple byte- 380 ranges in a single request. 382 When a client requests multiple byte-ranges in one request, the 383 server SHOULD return them in the order that they appeared in the 384 request. 386 If the server ignores a byte-range-spec because it is syntactically 387 invalid, the server SHOULD treat the request as if the invalid Range 388 header field did not exist. (Normally, this means return a 200 389 response containing the full entity). 391 If the server receives a request (other than one including an If- 392 Range request-header field) with an unsatisfiable Range request- 393 header field (that is, all of whose byte-range-spec values have a 394 first-byte-pos value greater than the current length of the selected 395 resource), it SHOULD return a response code of 416 (Requested range 396 not satisfiable) (Section 4.2). 398 Note: clients cannot depend on servers to send a 416 (Requested 399 range not satisfiable) response instead of a 200 (OK) response for 400 an unsatisfiable Range request-header, since not all servers 401 implement this request-header. 403 6.3. If-Range 405 If a client has a partial copy of an entity in its cache, and wishes 406 to have an up-to-date copy of the entire entity in its cache, it 407 could use the Range request-header with a conditional GET (using 408 either or both of If-Unmodified-Since and If-Match.) However, if the 409 condition fails because the entity has been modified, the client 410 would then have to make a second request to obtain the entire current 411 entity-body. 413 The If-Range header allows a client to "short-circuit" the second 414 request. Informally, its meaning is `if the entity is unchanged, 415 send me the part(s) that I am missing; otherwise, send me the entire 416 new entity'. 418 If-Range = "If-Range" ":" ( entity-tag | HTTP-date ) 420 If the client has no entity tag for an entity, but does have a Last- 421 Modified date, it MAY use that date in an If-Range header. (The 422 server can distinguish between a valid HTTP-date and any form of 423 entity-tag by examining no more than two characters.) The If-Range 424 header SHOULD only be used together with a Range header, and MUST be 425 ignored if the request does not include a Range header, or if the 426 server does not support the sub-range operation. 428 If the entity tag given in the If-Range header matches the current 429 entity tag for the entity, then the server SHOULD provide the 430 specified sub-range of the entity using a 206 (Partial Content) 431 response. If the entity tag does not match, then the server SHOULD 432 return the entire entity using a 200 (OK) response. 434 6.4. Range 436 6.4.1. Byte Ranges 438 Since all HTTP entities are represented in HTTP messages as sequences 439 of bytes, the concept of a byte range is meaningful for any HTTP 440 entity. (However, not all clients and servers need to support byte- 441 range operations.) 443 Byte range specifications in HTTP apply to the sequence of bytes in 444 the entity-body (not necessarily the same as the message-body). 446 A byte range operation MAY specify a single range of bytes, or a set 447 of ranges within a single entity. 449 ranges-specifier = byte-ranges-specifier 450 byte-ranges-specifier = bytes-unit "=" byte-range-set 451 byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec ) 452 byte-range-spec = first-byte-pos "-" [last-byte-pos] 453 first-byte-pos = 1*DIGIT 454 last-byte-pos = 1*DIGIT 456 The first-byte-pos value in a byte-range-spec gives the byte-offset 457 of the first byte in a range. The last-byte-pos value gives the 458 byte-offset of the last byte in the range; that is, the byte 459 positions specified are inclusive. Byte offsets start at zero. 461 If the last-byte-pos value is present, it MUST be greater than or 462 equal to the first-byte-pos in that byte-range-spec, or the byte- 463 range-spec is syntactically invalid. The recipient of a byte-range- 464 set that includes one or more syntactically invalid byte-range-spec 465 values MUST ignore the header field that includes that byte-range- 466 set. 468 If the last-byte-pos value is absent, or if the value is greater than 469 or equal to the current length of the entity-body, last-byte-pos is 470 taken to be equal to one less than the current length of the entity- 471 body in bytes. 473 By its choice of last-byte-pos, a client can limit the number of 474 bytes retrieved without knowing the size of the entity. 476 suffix-byte-range-spec = "-" suffix-length 477 suffix-length = 1*DIGIT 479 A suffix-byte-range-spec is used to specify the suffix of the entity- 480 body, of a length given by the suffix-length value. (That is, this 481 form specifies the last N bytes of an entity-body.) If the entity is 482 shorter than the specified suffix-length, the entire entity-body is 483 used. 485 If a syntactically valid byte-range-set includes at least one byte- 486 range-spec whose first-byte-pos is less than the current length of 487 the entity-body, or at least one suffix-byte-range-spec with a non- 488 zero suffix-length, then the byte-range-set is satisfiable. 489 Otherwise, the byte-range-set is unsatisfiable. If the byte-range- 490 set is unsatisfiable, the server SHOULD return a response with a 491 status of 416 (Requested range not satisfiable). Otherwise, the 492 server SHOULD return a response with a status of 206 (Partial 493 Content) containing the satisfiable ranges of the entity-body. 495 Examples of byte-ranges-specifier values (assuming an entity-body of 496 length 10000): 498 o The first 500 bytes (byte offsets 0-499, inclusive): bytes=0-499 500 o The second 500 bytes (byte offsets 500-999, inclusive): bytes=500- 501 999 503 o The final 500 bytes (byte offsets 9500-9999, inclusive): bytes=- 504 500 506 o Or bytes=9500- 508 o The first and last bytes only (bytes 0 and 9999): bytes=0-0,-1 510 o Several legal but not canonical specifications of the second 500 511 bytes (byte offsets 500-999, inclusive): 512 bytes=500-600,601-999 513 bytes=500-700,601-999 515 6.4.2. Range Retrieval Requests 517 HTTP retrieval requests using conditional or unconditional GET 518 methods MAY request one or more sub-ranges of the entity, instead of 519 the entire entity, using the Range request header, which applies to 520 the entity returned as the result of the request: 522 Range = "Range" ":" ranges-specifier 524 A server MAY ignore the Range header. However, HTTP/1.1 origin 525 servers and intermediate caches ought to support byte ranges when 526 possible, since Range supports efficient recovery from partially 527 failed transfers, and supports efficient partial retrieval of large 528 entities. 530 If the server supports the Range header and the specified range or 531 ranges are appropriate for the entity: 533 o The presence of a Range header in an unconditional GET modifies 534 what is returned if the GET is otherwise successful. In other 535 words, the response carries a status code of 206 (Partial Content) 536 instead of 200 (OK). 538 o The presence of a Range header in a conditional GET (a request 539 using one or both of If-Modified-Since and If-None-Match, or one 540 or both of If-Unmodified-Since and If-Match) modifies what is 541 returned if the GET is otherwise successful and the condition is 542 true. It does not affect the 304 (Not Modified) response returned 543 if the conditional is false. 545 In some cases, it might be more appropriate to use the If-Range 546 header (see Section 6.3) in addition to the Range header. 548 If a proxy that supports ranges receives a Range request, forwards 549 the request to an inbound server, and receives an entire entity in 550 reply, it SHOULD only return the requested range to its client. It 551 SHOULD store the entire received response in its cache if that is 552 consistent with its cache allocation policies. 554 7. IANA Considerations 556 7.1. Message Header Registration 558 The Message Header Registry located at should be 560 updated with the permanent registrations below (see [RFC3864]): 562 +-------------------+----------+----------+-------------+ 563 | Header Field Name | Protocol | Status | Reference | 564 +-------------------+----------+----------+-------------+ 565 | Accept-Ranges | http | standard | Section 6.1 | 566 | Content-Range | http | standard | Section 6.2 | 567 | If-Range | http | standard | Section 6.3 | 568 | Range | http | standard | Section 6.4 | 569 +-------------------+----------+----------+-------------+ 571 The change controller is: "IETF (iesg@ietf.org) - Internet 572 Engineering Task Force". 574 8. Security Considerations 576 No additional security considerations have been identified beyond 577 those applicable to HTTP in general [Part1]. 579 9. Acknowledgments 581 Most of the specification of ranges is based on work originally done 582 by Ari Luotonen and John Franks, with additional input from Steve 583 Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin 584 Hamilton, Koen Holtman, Shel Kaplan, Paul Leach, Alex Lopez-Ortiz, 585 Larry Masinter, Jeff Mogul, Lou Montulli, David W. Morris, Luigi 586 Rizzo, and Bill Weihl. 588 10. References 590 10.1. Normative References 592 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 593 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 594 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, 595 and Message Parsing", draft-ietf-httpbis-p1-messaging-04 596 (work in progress), August 2008. 598 [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 599 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 600 and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload 601 and Content Negotiation", draft-ietf-httpbis-p3-payload-04 602 (work in progress), August 2008. 604 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 605 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 606 and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional 607 Requests", draft-ietf-httpbis-p4-conditional-04 (work in 608 progress), August 2008. 610 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 611 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 612 and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", 613 draft-ietf-httpbis-p6-cache-04 (work in progress), 614 August 2008. 616 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 617 Extensions (MIME) Part Two: Media Types", RFC 2046, 618 November 1996. 620 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 621 Requirement Levels", BCP 14, RFC 2119, March 1997. 623 10.2. Informative References 625 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 626 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 627 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 629 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 630 Procedures for Message Header Fields", BCP 90, RFC 3864, 631 September 2004. 633 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 634 Registration Procedures", BCP 13, RFC 4288, December 2005. 636 Appendix A. Internet Media Type multipart/byteranges 638 When an HTTP 206 (Partial Content) response message includes the 639 content of multiple ranges (a response to a request for multiple non- 640 overlapping ranges), these are transmitted as a multipart message- 641 body [RFC2046]. The media type for this purpose is called 642 "multipart/byteranges". The following is to be registered with IANA 643 [RFC4288]. 645 The multipart/byteranges media type includes two or more parts, each 646 with its own Content-Type and Content-Range fields. The required 647 boundary parameter specifies the boundary string used to separate 648 each body-part. 650 Type name: multipart 652 Subtype name: byteranges 654 Required parameters: boundary 656 Optional parameters: none 658 Encoding considerations: only "7bit", "8bit", or "binary" are 659 permitted 661 Security considerations: none 663 Interoperability considerations: none 665 Published specification: This specification (see Appendix A). 667 Applications that use this media type: 669 Additional information: 671 Magic number(s): none 673 File extension(s): none 675 Macintosh file type code(s): none 677 Person and email address to contact for further information: See 678 Authors Section. 680 Intended usage: COMMON 682 Restrictions on usage: none 684 Author/Change controller: IESG 686 For example: 688 HTTP/1.1 206 Partial Content 689 Date: Wed, 15 Nov 1995 06:25:24 GMT 690 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 691 Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES 693 --THIS_STRING_SEPARATES 694 Content-type: application/pdf 695 Content-range: bytes 500-999/8000 697 ...the first range... 698 --THIS_STRING_SEPARATES 699 Content-type: application/pdf 700 Content-range: bytes 7000-7999/8000 702 ...the second range 703 --THIS_STRING_SEPARATES-- 705 Notes: 707 1. Additional CRLFs may precede the first boundary string in the 708 entity. 710 2. Although [RFC2046] permits the boundary string to be quoted, some 711 existing implementations handle a quoted boundary string 712 incorrectly. 714 3. A number of browsers and servers were coded to an early draft of 715 the byteranges specification to use a media type of multipart/ 716 x-byteranges, which is almost, but not quite compatible with the 717 version documented in HTTP/1.1. 719 Appendix B. Compatibility with Previous Versions 721 B.1. Changes from RFC 2068 723 Transfer-coding and message lengths all interact in ways that 724 required fixing exactly when chunked encoding is used (to allow for 725 transfer encoding that may not be self delimiting); it was important 726 to straighten out exactly how message lengths are computed. 727 (Section 6.2, see also [Part1], [Part3] and [Part6]) 729 There are situations where a server (especially a proxy) does not 730 know the full length of a response but is capable of serving a 731 byterange request. We therefore need a mechanism to allow byteranges 732 with a content-range not indicating the full length of the message. 733 (Section 6.2) 735 Range request responses would become very verbose if all meta-data 736 were always returned; by allowing the server to only send needed 737 headers in a 206 response, this problem can be avoided. (Section 4.1 738 and 6.3) 740 Fix problem with unsatisfiable range requests; there are two cases: 741 syntactic problems, and range doesn't exist in the document. The 416 742 status code was needed to resolve this ambiguity needed to indicate 743 an error for a byte range request that falls outside of the actual 744 contents of a document. (Section 4.2, 6.2) 746 B.2. Changes from RFC 2616 748 Clarify that it is not ok to use a weak cache validator in a 206 749 response. (Section 4.1) 751 Appendix C. Change Log (to be removed by RFC Editor before publication) 753 C.1. Since RFC2616 755 Extracted relevant partitions from [RFC2616]. 757 C.2. Since draft-ietf-httpbis-p5-range-00 759 Closed issues: 761 o : "Cache 762 validators in 206 responses" 763 () 765 o : "Normative 766 and Informative references" 768 o : "Normative 769 up-to-date references" 771 C.3. Since draft-ietf-httpbis-p5-range-01 773 Closed issues: 775 o : "Updating 776 to RFC4288" 778 Ongoing work on ABNF conversion 779 (): 781 o Add explicit references to BNF syntax and rules imported from 782 other parts of the specification. 784 C.4. Since draft-ietf-httpbis-p5-range-02 786 Ongoing work on IANA Message Header Registration 787 (): 789 o Reference RFC 3984, and update header registrations for headers 790 defined in this document. 792 C.5. Since draft-ietf-httpbis-p5-range-03 794 Index 796 2 797 206 Partial Content (status code) 5 799 4 800 416 Requested Range Not Satisfiable (status code) 6 802 A 803 Accept-Ranges header 7 805 C 806 Content-Range header 8 808 G 809 Grammar 810 Accept-Ranges 7 811 acceptable-ranges 7 812 byte-content-range-spec 8 813 byte-range-resp-spec 8 814 byte-range-set 11 815 byte-range-spec 11 816 byte-ranges-specifier 11 817 bytes-unit 5 818 Content-Range 8 819 content-range-spec 8 820 first-byte-pos 11 821 If-Range 10 822 instance-length 8 823 last-byte-pos 11 824 other-range-unit 5 825 Range 12 826 range-unit 5 827 ranges-specifier 11 828 suffix-byte-range-spec 11 829 suffix-length 11 831 H 832 Headers 833 Accept-Ranges 7 834 Content-Range 8 835 If-Range 10 836 Range 10 838 I 839 If-Range header 10 841 M 842 Media Type 843 multipart/byteranges 15 844 multipart/x-byteranges 17 845 multipart/byteranges Media Type 15 846 multipart/x-byteranges Media Type 17 848 R 849 Range header 10 851 S 852 Status Codes 853 206 Partial Content 5 854 416 Requested Range Not Satisfiable 6 856 Authors' Addresses 858 Roy T. Fielding (editor) 859 Day Software 860 23 Corporate Plaza DR, Suite 280 861 Newport Beach, CA 92660 862 USA 864 Phone: +1-949-706-5300 865 Fax: +1-949-706-5305 866 Email: fielding@gbiv.com 867 URI: http://roy.gbiv.com/ 869 Jim Gettys 870 One Laptop per Child 871 21 Oak Knoll Road 872 Carlisle, MA 01741 873 USA 875 Email: jg@laptop.org 876 URI: http://www.laptop.org/ 878 Jeffrey C. Mogul 879 Hewlett-Packard Company 880 HP Labs, Large Scale Systems Group 881 1501 Page Mill Road, MS 1177 882 Palo Alto, CA 94304 883 USA 885 Email: JeffMogul@acm.org 887 Henrik Frystyk Nielsen 888 Microsoft Corporation 889 1 Microsoft Way 890 Redmond, WA 98052 891 USA 893 Email: henrikn@microsoft.com 894 Larry Masinter 895 Adobe Systems, Incorporated 896 345 Park Ave 897 San Jose, CA 95110 898 USA 900 Email: LMM@acm.org 901 URI: http://larry.masinter.net/ 903 Paul J. Leach 904 Microsoft Corporation 905 1 Microsoft Way 906 Redmond, WA 98052 908 Email: paulle@microsoft.com 910 Tim Berners-Lee 911 World Wide Web Consortium 912 MIT Computer Science and Artificial Intelligence Laboratory 913 The Stata Center, Building 32 914 32 Vassar Street 915 Cambridge, MA 02139 916 USA 918 Email: timbl@w3.org 919 URI: http://www.w3.org/People/Berners-Lee/ 921 Yves Lafon (editor) 922 World Wide Web Consortium 923 W3C / ERCIM 924 2004, rte des Lucioles 925 Sophia-Antipolis, AM 06902 926 France 928 Email: ylafon@w3.org 929 URI: http://www.raubacapeu.net/people/yves/ 930 Julian F. Reschke (editor) 931 greenbytes GmbH 932 Hafenweg 16 933 Muenster, NW 48155 934 Germany 936 Phone: +49 251 2807760 937 Fax: +49 251 2807761 938 Email: julian.reschke@greenbytes.de 939 URI: http://greenbytes.de/tech/webdav/ 941 Full Copyright Statement 943 Copyright (C) The IETF Trust (2008). 945 This document is subject to the rights, licenses and restrictions 946 contained in BCP 78, and except as set forth therein, the authors 947 retain all their rights. 949 This document and the information contained herein are provided on an 950 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 951 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 952 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 953 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 954 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 955 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 957 Intellectual Property 959 The IETF takes no position regarding the validity or scope of any 960 Intellectual Property Rights or other rights that might be claimed to 961 pertain to the implementation or use of the technology described in 962 this document or the extent to which any license under such rights 963 might or might not be available; nor does it represent that it has 964 made any independent effort to identify any such rights. Information 965 on the procedures with respect to rights in RFC documents can be 966 found in BCP 78 and BCP 79. 968 Copies of IPR disclosures made to the IETF Secretariat and any 969 assurances of licenses to be made available, or the result of an 970 attempt made to obtain a general license or permission for the use of 971 such proprietary rights by implementers or users of this 972 specification can be obtained from the IETF on-line IPR repository at 973 http://www.ietf.org/ipr. 975 The IETF invites any interested party to bring to its attention any 976 copyrights, patents or patent applications, or other proprietary 977 rights that may cover technology that may be required to implement 978 this standard. Please address the information to the IETF at 979 ietf-ipr@ietf.org.