idnits 2.17.1 draft-ietf-httpbis-p5-range-05.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 983. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 994. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1001. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1007. 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 (November 16, 2008) is 5634 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-05 == Outdated reference: A later version (-20) exists of draft-ietf-httpbis-p3-payload-05 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-05 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-05 -- 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: May 20, 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 November 16, 2008 22 HTTP/1.1, part 5: Range Requests and Partial Responses 23 draft-ietf-httpbis-p5-range-05 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 May 20, 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.6. 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 . . . . . . . . . . . . . . . . . . . . . 11 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 C.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 18 107 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 109 Intellectual Property and Copyright Statements . . . . . . . . . . 23 111 1. Introduction 113 HTTP clients often encounter interrupted data transfers as a result 114 of cancelled requests or dropped connections. When a cache has 115 stored a partial representation, it is desirable to request the 116 remainder of that representation in a subsequent request rather than 117 transfer the entire representation. There are also a number of Web 118 applications that benefit from being able to request only a subset of 119 a larger representation, such as a single page of a very large 120 document or only part of an image to be rendered by a device with 121 limited local storage. 123 This document defines HTTP/1.1 range requests, partial responses, and 124 the multipart/byteranges media type. The protocol for range requests 125 is an OPTIONAL feature of HTTP, designed so resources or recipients 126 that do not implement this feature can respond as if it is a normal 127 GET request without impacting interoperability. Partial responses 128 are indicated by a distinct status code to not be mistaken for full 129 responses by intermediate caches that might not implement the 130 feature. 132 Although the HTTP range request mechanism is designed to allow for 133 extensible range types, this specification only defines requests for 134 byte ranges. 136 1.1. Requirements 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 An implementation is not compliant if it fails to satisfy one or more 143 of the MUST or REQUIRED level requirements for the protocols it 144 implements. An implementation that satisfies all the MUST or 145 REQUIRED level and all the SHOULD level requirements for its 146 protocols is said to be "unconditionally compliant"; one that 147 satisfies all the MUST level requirements but not all the SHOULD 148 level requirements for its protocols is said to be "conditionally 149 compliant." 151 2. Notational Conventions and Generic Grammar 153 This specification uses the ABNF syntax defined in Section 2.1 of 154 [Part1] and the core rules defined in Section 2.2 of [Part1]: 156 DIGIT = 157 SP = 158 token = 159 OWS = 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 ranges-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 response-header "Accept-Ranges" field allows the server to 276 indicate its acceptance of range requests for a resource: 278 Accept-Ranges = "Accept-Ranges" ":" OWS Accept-Ranges-v 279 Accept-Ranges-v = acceptable-ranges 280 acceptable-ranges = 1#range-unit / "none" 282 Origin servers that accept byte-range requests MAY send 284 Accept-Ranges: bytes 286 but are not required to do so. Clients MAY generate byte-range 287 requests without having received this header for the resource 288 involved. Range units are defined in Section 3. 290 Servers that do not accept any kind of range request for a resource 291 MAY send 293 Accept-Ranges: none 295 to advise the client not to attempt a range request. 297 6.2. Content-Range 299 The entity-header "Content-Range" is sent with a partial entity-body 300 to specify where in the full entity-body the partial body should be 301 applied. Range units are defined in Section 3. 303 Content-Range = "Content-Range" ":" OWS Content-Range-v 304 Content-Range-v = content-range-spec 306 content-range-spec = byte-content-range-spec 307 byte-content-range-spec = bytes-unit SP 308 byte-range-resp-spec "/" 309 ( instance-length / "*" ) 311 byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) 312 / "*" 314 instance-length = 1*DIGIT 316 The header SHOULD indicate the total length of the full entity-body, 317 unless this length is unknown or difficult to determine. The 318 asterisk "*" character means that the instance-length is unknown at 319 the time when the response was generated. 321 Unlike byte-ranges-specifier values (see Section 6.4.1), a byte- 322 range-resp-spec MUST only specify one range, and MUST contain 323 absolute byte positions for both the first and last byte of the 324 range. 326 A byte-content-range-spec with a byte-range-resp-spec whose last- 327 byte-pos value is less than its first-byte-pos value, or whose 328 instance-length value is less than or equal to its last-byte-pos 329 value, is invalid. The recipient of an invalid byte-content-range- 330 spec MUST ignore it and any content transferred along with it. 332 A server sending a response with status code 416 (Requested range not 333 satisfiable) SHOULD include a Content-Range field with a byte-range- 334 resp-spec of "*". The instance-length specifies the current length 335 of the selected resource. A response with status code 206 (Partial 336 Content) MUST NOT include a Content-Range field with a byte-range- 337 resp-spec of "*". 339 Examples of byte-content-range-spec values, assuming that the entity 340 contains a total of 1234 bytes: 342 o The first 500 bytes: 344 bytes 0-499/1234 346 o The second 500 bytes: 348 bytes 500-999/1234 350 o All except for the first 500 bytes: 352 bytes 500-1233/1234 354 o The last 500 bytes: 356 bytes 734-1233/1234 358 When an HTTP message includes the content of a single range (for 359 example, a response to a request for a single range, or to a request 360 for a set of ranges that overlap without any holes), this content is 361 transmitted with a Content-Range header, and a Content-Length header 362 showing the number of bytes actually transferred. For example, 364 HTTP/1.1 206 Partial Content 365 Date: Wed, 15 Nov 1995 06:25:24 GMT 366 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 367 Content-Range: bytes 21010-47021/47022 368 Content-Length: 26012 369 Content-Type: image/gif 371 When an HTTP message includes the content of multiple ranges (for 372 example, a response to a request for multiple non-overlapping 373 ranges), these are transmitted as a multipart message. The multipart 374 media type used for this purpose is "multipart/byteranges" as defined 375 in Appendix A. See Appendix B.1 for a compatibility issue. 377 A response to a request for a single range MUST NOT be sent using the 378 multipart/byteranges media type. A response to a request for 379 multiple ranges, whose result is a single range, MAY be sent as a 380 multipart/byteranges media type with one part. A client that cannot 381 decode a multipart/byteranges message MUST NOT ask for multiple byte- 382 ranges in a single request. 384 When a client requests multiple byte-ranges in one request, the 385 server SHOULD return them in the order that they appeared in the 386 request. 388 If the server ignores a byte-range-spec because it is syntactically 389 invalid, the server SHOULD treat the request as if the invalid Range 390 header field did not exist. (Normally, this means return a 200 391 response containing the full entity). 393 If the server receives a request (other than one including an If- 394 Range request-header field) with an unsatisfiable Range request- 395 header field (that is, all of whose byte-range-spec values have a 396 first-byte-pos value greater than the current length of the selected 397 resource), it SHOULD return a response code of 416 (Requested range 398 not satisfiable) (Section 4.2). 400 Note: clients cannot depend on servers to send a 416 (Requested 401 range not satisfiable) response instead of a 200 (OK) response for 402 an unsatisfiable Range request-header, since not all servers 403 implement this request-header. 405 6.3. If-Range 407 If a client has a partial copy of an entity in its cache, and wishes 408 to have an up-to-date copy of the entire entity in its cache, it 409 could use the Range request-header with a conditional GET (using 410 either or both of If-Unmodified-Since and If-Match.) However, if the 411 condition fails because the entity has been modified, the client 412 would then have to make a second request to obtain the entire current 413 entity-body. 415 The request header "If-Range" allows a client to "short-circuit" the 416 second request. Informally, its meaning is `if the entity is 417 unchanged, send me the part(s) that I am missing; otherwise, send me 418 the entire new entity'. 420 If-Range = "If-Range" ":" OWS If-Range-v 421 If-Range-v = entity-tag / HTTP-date 423 If the client has no entity tag for an entity, but does have a Last- 424 Modified date, it MAY use that date in an If-Range header. (The 425 server can distinguish between a valid HTTP-date and any form of 426 entity-tag by examining no more than two characters.) The If-Range 427 header SHOULD only be used together with a Range header, and MUST be 428 ignored if the request does not include a Range header, or if the 429 server does not support the sub-range operation. 431 If the entity tag given in the If-Range header matches the current 432 entity tag for the entity, then the server SHOULD provide the 433 specified sub-range of the entity using a 206 (Partial Content) 434 response. If the entity tag does not match, then the server SHOULD 435 return the entire entity using a 200 (OK) response. 437 6.4. Range 438 6.4.1. Byte Ranges 440 Since all HTTP entities are represented in HTTP messages as sequences 441 of bytes, the concept of a byte range is meaningful for any HTTP 442 entity. (However, not all clients and servers need to support byte- 443 range operations.) 445 Byte range specifications in HTTP apply to the sequence of bytes in 446 the entity-body (not necessarily the same as the message-body). 448 A byte range operation MAY specify a single range of bytes, or a set 449 of ranges within a single entity. 451 ranges-specifier = byte-ranges-specifier 452 byte-ranges-specifier = bytes-unit "=" byte-range-set 453 byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec ) 454 byte-range-spec = first-byte-pos "-" [last-byte-pos] 455 first-byte-pos = 1*DIGIT 456 last-byte-pos = 1*DIGIT 458 The first-byte-pos value in a byte-range-spec gives the byte-offset 459 of the first byte in a range. The last-byte-pos value gives the 460 byte-offset of the last byte in the range; that is, the byte 461 positions specified are inclusive. Byte offsets start at zero. 463 If the last-byte-pos value is present, it MUST be greater than or 464 equal to the first-byte-pos in that byte-range-spec, or the byte- 465 range-spec is syntactically invalid. The recipient of a byte-range- 466 set that includes one or more syntactically invalid byte-range-spec 467 values MUST ignore the header field that includes that byte-range- 468 set. 470 If the last-byte-pos value is absent, or if the value is greater than 471 or equal to the current length of the entity-body, last-byte-pos is 472 taken to be equal to one less than the current length of the entity- 473 body in bytes. 475 By its choice of last-byte-pos, a client can limit the number of 476 bytes retrieved without knowing the size of the entity. 478 suffix-byte-range-spec = "-" suffix-length 479 suffix-length = 1*DIGIT 481 A suffix-byte-range-spec is used to specify the suffix of the entity- 482 body, of a length given by the suffix-length value. (That is, this 483 form specifies the last N bytes of an entity-body.) If the entity is 484 shorter than the specified suffix-length, the entire entity-body is 485 used. 487 If a syntactically valid byte-range-set includes at least one byte- 488 range-spec whose first-byte-pos is less than the current length of 489 the entity-body, or at least one suffix-byte-range-spec with a non- 490 zero suffix-length, then the byte-range-set is satisfiable. 491 Otherwise, the byte-range-set is unsatisfiable. If the byte-range- 492 set is unsatisfiable, the server SHOULD return a response with a 493 status of 416 (Requested range not satisfiable). Otherwise, the 494 server SHOULD return a response with a status of 206 (Partial 495 Content) containing the satisfiable ranges of the entity-body. 497 Examples of byte-ranges-specifier values (assuming an entity-body of 498 length 10000): 500 o The first 500 bytes (byte offsets 0-499, inclusive): bytes=0-499 502 o The second 500 bytes (byte offsets 500-999, inclusive): bytes=500- 503 999 505 o The final 500 bytes (byte offsets 9500-9999, inclusive): bytes=- 506 500 508 o Or bytes=9500- 510 o The first and last bytes only (bytes 0 and 9999): bytes=0-0,-1 512 o Several legal but not canonical specifications of the second 500 513 bytes (byte offsets 500-999, inclusive): 514 bytes=500-600,601-999 515 bytes=500-700,601-999 517 6.4.2. Range Retrieval Requests 519 HTTP retrieval requests using conditional or unconditional GET 520 methods MAY request one or more sub-ranges of the entity, instead of 521 the entire entity, using the Range request header, which applies to 522 the entity returned as the result of the request: 524 Range = "Range" ":" OWS Range-v 525 Range-v = ranges-specifier 527 A server MAY ignore the Range header. However, HTTP/1.1 origin 528 servers and intermediate caches ought to support byte ranges when 529 possible, since Range supports efficient recovery from partially 530 failed transfers, and supports efficient partial retrieval of large 531 entities. 533 If the server supports the Range header and the specified range or 534 ranges are appropriate for the entity: 536 o The presence of a Range header in an unconditional GET modifies 537 what is returned if the GET is otherwise successful. In other 538 words, the response carries a status code of 206 (Partial Content) 539 instead of 200 (OK). 541 o The presence of a Range header in a conditional GET (a request 542 using one or both of If-Modified-Since and If-None-Match, or one 543 or both of If-Unmodified-Since and If-Match) modifies what is 544 returned if the GET is otherwise successful and the condition is 545 true. It does not affect the 304 (Not Modified) response returned 546 if the conditional is false. 548 In some cases, it might be more appropriate to use the If-Range 549 header (see Section 6.3) in addition to the Range header. 551 If a proxy that supports ranges receives a Range request, forwards 552 the request to an inbound server, and receives an entire entity in 553 reply, it SHOULD only return the requested range to its client. It 554 SHOULD store the entire received response in its cache if that is 555 consistent with its cache allocation policies. 557 7. IANA Considerations 559 7.1. Message Header Registration 561 The Message Header Registry located at should be 563 updated with the permanent registrations below (see [RFC3864]): 565 +-------------------+----------+----------+-------------+ 566 | Header Field Name | Protocol | Status | Reference | 567 +-------------------+----------+----------+-------------+ 568 | Accept-Ranges | http | standard | Section 6.1 | 569 | Content-Range | http | standard | Section 6.2 | 570 | If-Range | http | standard | Section 6.3 | 571 | Range | http | standard | Section 6.4 | 572 +-------------------+----------+----------+-------------+ 574 The change controller is: "IETF (iesg@ietf.org) - Internet 575 Engineering Task Force". 577 8. Security Considerations 579 No additional security considerations have been identified beyond 580 those applicable to HTTP in general [Part1]. 582 9. Acknowledgments 584 Most of the specification of ranges is based on work originally done 585 by Ari Luotonen and John Franks, with additional input from Steve 586 Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin 587 Hamilton, Koen Holtman, Shel Kaplan, Paul Leach, Alex Lopez-Ortiz, 588 Larry Masinter, Jeff Mogul, Lou Montulli, David W. Morris, Luigi 589 Rizzo, and Bill Weihl. 591 10. References 593 10.1. Normative References 595 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 596 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 597 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, 598 and Message Parsing", draft-ietf-httpbis-p1-messaging-05 599 (work in progress), November 2008. 601 [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 602 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 603 and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload 604 and Content Negotiation", draft-ietf-httpbis-p3-payload-05 605 (work in progress), November 2008. 607 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 608 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 609 and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional 610 Requests", draft-ietf-httpbis-p4-conditional-05 (work in 611 progress), November 2008. 613 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 614 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 615 and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", 616 draft-ietf-httpbis-p6-cache-05 (work in progress), 617 November 2008. 619 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 620 Extensions (MIME) Part Two: Media Types", RFC 2046, 621 November 1996. 623 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 624 Requirement Levels", BCP 14, RFC 2119, March 1997. 626 10.2. Informative References 628 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 629 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 630 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 632 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 633 Procedures for Message Header Fields", BCP 90, RFC 3864, 634 September 2004. 636 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 637 Registration Procedures", BCP 13, RFC 4288, December 2005. 639 Appendix A. Internet Media Type multipart/byteranges 641 When an HTTP 206 (Partial Content) response message includes the 642 content of multiple ranges (a response to a request for multiple non- 643 overlapping ranges), these are transmitted as a multipart message- 644 body ([RFC2046], Section 5.1). The media type for this purpose is 645 called "multipart/byteranges". The following is to be registered 646 with IANA [RFC4288]. 648 The multipart/byteranges media type includes one or more parts, each 649 with its own Content-Type and Content-Range fields. The required 650 boundary parameter specifies the boundary string used to separate 651 each body-part. 653 Type name: multipart 655 Subtype name: byteranges 657 Required parameters: boundary 659 Optional parameters: none 661 Encoding considerations: only "7bit", "8bit", or "binary" are 662 permitted 664 Security considerations: none 666 Interoperability considerations: none 668 Published specification: This specification (see Appendix A). 670 Applications that use this media type: 672 Additional information: 674 Magic number(s): none 676 File extension(s): none 678 Macintosh file type code(s): none 680 Person and email address to contact for further information: See 681 Authors Section. 683 Intended usage: COMMON 685 Restrictions on usage: none 687 Author/Change controller: IESG 689 For example: 691 HTTP/1.1 206 Partial Content 692 Date: Wed, 15 Nov 1995 06:25:24 GMT 693 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 694 Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES 696 --THIS_STRING_SEPARATES 697 Content-type: application/pdf 698 Content-range: bytes 500-999/8000 700 ...the first range... 701 --THIS_STRING_SEPARATES 702 Content-type: application/pdf 703 Content-range: bytes 7000-7999/8000 705 ...the second range 706 --THIS_STRING_SEPARATES-- 708 Notes: 710 1. Additional CRLFs may precede the first boundary string in the 711 entity. 713 2. Although [RFC2046] permits the boundary string to be quoted, some 714 existing implementations handle a quoted boundary string 715 incorrectly. 717 3. A number of browsers and servers were coded to an early draft of 718 the byteranges specification to use a media type of multipart/ 719 x-byteranges, which is almost, but not quite compatible with the 720 version documented in HTTP/1.1. 722 Appendix B. Compatibility with Previous Versions 724 B.1. Changes from RFC 2068 726 Transfer-coding and message lengths all interact in ways that 727 required fixing exactly when chunked encoding is used (to allow for 728 transfer encoding that may not be self delimiting); it was important 729 to straighten out exactly how message lengths are computed. 730 (Section 6.2, see also [Part1], [Part3] and [Part6]) 732 There are situations where a server (especially a proxy) does not 733 know the full length of a response but is capable of serving a 734 byterange request. We therefore need a mechanism to allow byteranges 735 with a content-range not indicating the full length of the message. 736 (Section 6.2) 738 Range request responses would become very verbose if all meta-data 739 were always returned; by allowing the server to only send needed 740 headers in a 206 response, this problem can be avoided. (Section 4.1 741 and 6.3) 743 Fix problem with unsatisfiable range requests; there are two cases: 744 syntactic problems, and range doesn't exist in the document. The 416 745 status code was needed to resolve this ambiguity needed to indicate 746 an error for a byte range request that falls outside of the actual 747 contents of a document. (Section 4.2, 6.2) 749 B.2. Changes from RFC 2616 751 Clarify that it is not ok to use a weak cache validator in a 206 752 response. (Section 4.1) 754 Clarify that multipart/byteranges can consist of a single part. 755 (Appendix A) 757 Appendix C. Change Log (to be removed by RFC Editor before publication) 759 C.1. Since RFC2616 761 Extracted relevant partitions from [RFC2616]. 763 C.2. Since draft-ietf-httpbis-p5-range-00 765 Closed issues: 767 o : "Cache 768 validators in 206 responses" 769 () 771 o : "Normative and 772 Informative references" 774 o : "Normative up- 775 to-date references" 777 C.3. Since draft-ietf-httpbis-p5-range-01 779 Closed issues: 781 o : "Updating to 782 RFC4288" 784 Ongoing work on ABNF conversion 785 (): 787 o Add explicit references to BNF syntax and rules imported from 788 other parts of the specification. 790 C.4. Since draft-ietf-httpbis-p5-range-02 792 Ongoing work on IANA Message Header Registration 793 (): 795 o Reference RFC 3984, and update header registrations for headers 796 defined in this document. 798 C.5. Since draft-ietf-httpbis-p5-range-03 800 C.6. Since draft-ietf-httpbis-p5-range-04 802 Closed issues: 804 o : "multipart/ 805 byteranges minimum number of parts" 807 Ongoing work on ABNF conversion 808 (): 810 o Use "/" instead of "|" for alternatives. 812 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 813 whitespace ("OWS") and required whitespace ("RWS"). 815 o Rewrite ABNFs to spell out whitespace rules, factor out header 816 value format definitions. 818 Index 820 2 821 206 Partial Content (status code) 5 823 4 824 416 Requested Range Not Satisfiable (status code) 6 826 A 827 Accept-Ranges header 7 829 C 830 Content-Range header 8 832 G 833 Grammar 834 Accept-Ranges 7 835 Accept-Ranges-v 7 836 acceptable-ranges 7 837 byte-content-range-spec 8 838 byte-range-resp-spec 8 839 byte-range-set 11 840 byte-range-spec 11 841 byte-ranges-specifier 11 842 bytes-unit 5 843 Content-Range 8 844 content-range-spec 8 845 Content-Range-v 8 846 first-byte-pos 11 847 If-Range 10 848 If-Range-v 10 849 instance-length 8 850 last-byte-pos 11 851 other-range-unit 5 852 Range 12 853 range-unit 5 854 Range-v 12 855 ranges-specifier 11 856 suffix-byte-range-spec 11 857 suffix-length 11 859 H 860 Headers 861 Accept-Ranges 7 862 Content-Range 8 863 If-Range 10 864 Range 10 866 I 867 If-Range header 10 869 M 870 Media Type 871 multipart/byteranges 15 872 multipart/x-byteranges 17 873 multipart/byteranges Media Type 15 874 multipart/x-byteranges Media Type 17 876 R 877 Range header 10 879 S 880 Status Codes 881 206 Partial Content 5 882 416 Requested Range Not Satisfiable 6 884 Authors' Addresses 886 Roy T. Fielding (editor) 887 Day Software 888 23 Corporate Plaza DR, Suite 280 889 Newport Beach, CA 92660 890 USA 892 Phone: +1-949-706-5300 893 Fax: +1-949-706-5305 894 Email: fielding@gbiv.com 895 URI: http://roy.gbiv.com/ 896 Jim Gettys 897 One Laptop per Child 898 21 Oak Knoll Road 899 Carlisle, MA 01741 900 USA 902 Email: jg@laptop.org 903 URI: http://www.laptop.org/ 905 Jeffrey C. Mogul 906 Hewlett-Packard Company 907 HP Labs, Large Scale Systems Group 908 1501 Page Mill Road, MS 1177 909 Palo Alto, CA 94304 910 USA 912 Email: JeffMogul@acm.org 914 Henrik Frystyk Nielsen 915 Microsoft Corporation 916 1 Microsoft Way 917 Redmond, WA 98052 918 USA 920 Email: henrikn@microsoft.com 922 Larry Masinter 923 Adobe Systems, Incorporated 924 345 Park Ave 925 San Jose, CA 95110 926 USA 928 Email: LMM@acm.org 929 URI: http://larry.masinter.net/ 931 Paul J. Leach 932 Microsoft Corporation 933 1 Microsoft Way 934 Redmond, WA 98052 936 Email: paulle@microsoft.com 937 Tim Berners-Lee 938 World Wide Web Consortium 939 MIT Computer Science and Artificial Intelligence Laboratory 940 The Stata Center, Building 32 941 32 Vassar Street 942 Cambridge, MA 02139 943 USA 945 Email: timbl@w3.org 946 URI: http://www.w3.org/People/Berners-Lee/ 948 Yves Lafon (editor) 949 World Wide Web Consortium 950 W3C / ERCIM 951 2004, rte des Lucioles 952 Sophia-Antipolis, AM 06902 953 France 955 Email: ylafon@w3.org 956 URI: http://www.raubacapeu.net/people/yves/ 958 Julian F. Reschke (editor) 959 greenbytes GmbH 960 Hafenweg 16 961 Muenster, NW 48155 962 Germany 964 Phone: +49 251 2807760 965 Fax: +49 251 2807761 966 Email: julian.reschke@greenbytes.de 967 URI: http://greenbytes.de/tech/webdav/ 969 Full Copyright Statement 971 Copyright (C) The IETF Trust (2008). 973 This document is subject to the rights, licenses and restrictions 974 contained in BCP 78, and except as set forth therein, the authors 975 retain all their rights. 977 This document and the information contained herein are provided on an 978 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 979 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 980 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 981 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 982 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 983 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 985 Intellectual Property 987 The IETF takes no position regarding the validity or scope of any 988 Intellectual Property Rights or other rights that might be claimed to 989 pertain to the implementation or use of the technology described in 990 this document or the extent to which any license under such rights 991 might or might not be available; nor does it represent that it has 992 made any independent effort to identify any such rights. Information 993 on the procedures with respect to rights in RFC documents can be 994 found in BCP 78 and BCP 79. 996 Copies of IPR disclosures made to the IETF Secretariat and any 997 assurances of licenses to be made available, or the result of an 998 attempt made to obtain a general license or permission for the use of 999 such proprietary rights by implementers or users of this 1000 specification can be obtained from the IETF on-line IPR repository at 1001 http://www.ietf.org/ipr. 1003 The IETF invites any interested party to bring to its attention any 1004 copyrights, patents or patent applications, or other proprietary 1005 rights that may cover technology that may be required to implement 1006 this standard. Please address the information to the IETF at 1007 ietf-ipr@ietf.org.