idnits 2.17.1 draft-ietf-httpbis-p5-range-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 11, 2011) is 4672 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-15 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-15 -- 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) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPbis Working Group R. Fielding, Ed. 3 Internet-Draft Adobe 4 Obsoletes: 2616 (if approved) J. Gettys 5 Intended status: Standards Track Alcatel-Lucent 6 Expires: January 12, 2012 J. Mogul 7 HP 8 H. Frystyk 9 Microsoft 10 L. Masinter 11 Adobe 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 July 11, 2011 22 HTTP/1.1, part 5: Range Requests and Partial Responses 23 draft-ietf-httpbis-p5-range-15 25 Abstract 27 The Hypertext Transfer Protocol (HTTP) is an application-level 28 protocol for distributed, collaborative, hypermedia information 29 systems. HTTP has been in use by the World Wide Web global 30 information initiative since 1990. This document is Part 5 of the 31 seven-part specification that defines the protocol referred to as 32 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines 33 range-specific requests and the rules for constructing and combining 34 responses to those requests. 36 Editorial Note (To be removed by RFC Editor) 38 Discussion of this draft should take place on the HTTPBIS working 39 group mailing list (ietf-http-wg@w3.org), which is archived at 40 . 42 The current issues list is at 43 and related 44 documents (including fancy diffs) can be found at 45 . 47 The changes in this draft are summarized in Appendix D.16. 49 Status of This Memo 51 This Internet-Draft is submitted in full conformance with the 52 provisions of BCP 78 and BCP 79. 54 Internet-Drafts are working documents of the Internet Engineering 55 Task Force (IETF). Note that other groups may also distribute 56 working documents as Internet-Drafts. The list of current Internet- 57 Drafts is at http://datatracker.ietf.org/drafts/current/. 59 Internet-Drafts are draft documents valid for a maximum of six months 60 and may be updated, replaced, or obsoleted by other documents at any 61 time. It is inappropriate to use Internet-Drafts as reference 62 material or to cite them other than as "work in progress." 64 This Internet-Draft will expire on January 12, 2012. 66 Copyright Notice 68 Copyright (c) 2011 IETF Trust and the persons identified as the 69 document authors. All rights reserved. 71 This document is subject to BCP 78 and the IETF Trust's Legal 72 Provisions Relating to IETF Documents 73 (http://trustee.ietf.org/license-info) in effect on the date of 74 publication of this document. Please review these documents 75 carefully, as they describe your rights and restrictions with respect 76 to this document. Code Components extracted from this document must 77 include Simplified BSD License text as described in Section 4.e of 78 the Trust Legal Provisions and are provided without warranty as 79 described in the Simplified BSD License. 81 This document may contain material from IETF Documents or IETF 82 Contributions published or made publicly available before November 83 10, 2008. The person(s) controlling the copyright in some of this 84 material may not have granted the IETF Trust the right to allow 85 modifications of such material outside the IETF Standards Process. 86 Without obtaining an adequate license from the person(s) controlling 87 the copyright in such materials, this document may not be modified 88 outside the IETF Standards Process, and derivative works of it may 89 not be created outside the IETF Standards Process, except to format 90 it for publication as an RFC or to translate it into languages other 91 than English. 93 Table of Contents 95 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 96 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 97 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 98 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6 99 1.2.2. ABNF Rules defined in other Parts of the 100 Specification . . . . . . . . . . . . . . . . . . . . 6 101 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 6 102 2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 6 103 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7 104 3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 7 105 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 8 106 4. Combining Ranges . . . . . . . . . . . . . . . . . . . . . . . 8 107 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 8 108 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 9 109 5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 9 110 5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 11 111 5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 12 112 5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 12 113 5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 14 114 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 115 6.1. Status Code Registration . . . . . . . . . . . . . . . . . 15 116 6.2. Header Field Registration . . . . . . . . . . . . . . . . 15 117 6.3. Range Specifier Registration . . . . . . . . . . . . . . . 16 118 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 119 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 120 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 121 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 122 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 123 Appendix A. Internet Media Type multipart/byteranges . . . . . . 17 124 Appendix B. Compatibility with Previous Versions . . . . . . . . 20 125 B.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 20 126 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 20 127 Appendix D. Change Log (to be removed by RFC Editor before 128 publication) . . . . . . . . . . . . . . . . . . . . 22 129 D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 22 130 D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 22 131 D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 22 132 D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 22 133 D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 23 134 D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 23 135 D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 23 136 D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 23 137 D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 24 138 D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 24 139 D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 24 140 D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 24 141 D.13. Since draft-ietf-httpbis-p5-range-11 . . . . . . . . . . . 24 142 D.14. Since draft-ietf-httpbis-p5-range-12 . . . . . . . . . . . 25 143 D.15. Since draft-ietf-httpbis-p5-range-13 . . . . . . . . . . . 25 144 D.16. Since draft-ietf-httpbis-p5-range-14 . . . . . . . . . . . 25 146 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 148 1. Introduction 150 HTTP clients often encounter interrupted data transfers as a result 151 of cancelled requests or dropped connections. When a cache has 152 stored a partial representation, it is desirable to request the 153 remainder of that representation in a subsequent request rather than 154 transfer the entire representation. There are also a number of Web 155 applications that benefit from being able to request only a subset of 156 a larger representation, such as a single page of a very large 157 document or only part of an image to be rendered by a device with 158 limited local storage. 160 This document defines HTTP/1.1 range requests, partial responses, and 161 the multipart/byteranges media type. The protocol for range requests 162 is an OPTIONAL feature of HTTP, designed so resources or recipients 163 that do not implement this feature can respond as if it is a normal 164 GET request without impacting interoperability. Partial responses 165 are indicated by a distinct status code to not be mistaken for full 166 responses by intermediate caches that might not implement the 167 feature. 169 Although the HTTP range request mechanism is designed to allow for 170 extensible range types, this specification only defines requests for 171 byte ranges. 173 1.1. Requirements 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in [RFC2119]. 179 An implementation is not compliant if it fails to satisfy one or more 180 of the "MUST" or "REQUIRED" level requirements for the protocols it 181 implements. An implementation that satisfies all the "MUST" or 182 "REQUIRED" level and all the "SHOULD" level requirements for its 183 protocols is said to be "unconditionally compliant"; one that 184 satisfies all the "MUST" level requirements but not all the "SHOULD" 185 level requirements for its protocols is said to be "conditionally 186 compliant". 188 1.2. Syntax Notation 190 This specification uses the ABNF syntax defined in Section 1.2 of 191 [Part1] (which extends the syntax defined in [RFC5234] with a list 192 rule). Appendix C shows the collected ABNF, with the list rule 193 expanded. 195 The following core rules are included by reference, as defined in 197 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 198 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 199 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit 200 sequence of data), SP (space), VCHAR (any visible USASCII character), 201 and WSP (whitespace). 203 1.2.1. Core Rules 205 The core rules below are defined in Section 1.2.2 of [Part1]: 207 token = 208 OWS = 210 1.2.2. ABNF Rules defined in other Parts of the Specification 212 The ABNF rules below are defined in other parts: 214 HTTP-date = 216 entity-tag = 218 2. Range Units 220 HTTP/1.1 allows a client to request that only part (a range) of the 221 representation be included within the response. HTTP/1.1 uses range 222 units in the Range (Section 5.4) and Content-Range (Section 5.2) 223 header fields. A representation can be broken down into subranges 224 according to various structural units. 226 range-unit = bytes-unit / other-range-unit 227 bytes-unit = "bytes" 228 other-range-unit = token 230 HTTP/1.1 has been designed to allow implementations of applications 231 that do not depend on knowledge of ranges. The only range unit 232 defined by HTTP/1.1 is "bytes". Additional specifiers can be defined 233 as described in Section 2.1. 235 If a range unit is not understood in a request, a server MUST ignore 236 the whole Range header field (Section 5.4). If a range unit is not 237 understood in a response, an intermediary SHOULD pass the response to 238 the client; a client MUST fail. 240 2.1. Range Specifier Registry 242 The HTTP Range Specifier Registry defines the name space for the 243 range specifier names. 245 Registrations MUST include the following fields: 247 o Name 249 o Description 251 o Pointer to specification text 253 Values to be added to this name space are subject to IETF review 254 ([RFC5226], Section 4.1). 256 The registry itself is maintained at 257 . 259 3. Status Code Definitions 261 3.1. 206 Partial Content 263 The server has fulfilled the partial GET request for the resource. 264 The request MUST have included a Range header field (Section 5.4) 265 indicating the desired range, and MAY have included an If-Range 266 header field (Section 5.3) to make the request conditional. 268 The response MUST include the following header fields: 270 o Either a Content-Range header field (Section 5.2) indicating the 271 range included with this response, or a multipart/byteranges 272 Content-Type including Content-Range fields for each part. If a 273 Content-Length header field is present in the response, its value 274 MUST match the actual number of octets transmitted in the message- 275 body. 277 o Date 279 o Cache-Control, ETag, Expires, Content-Location, Last-Modified, 280 and/or Vary, if the header field would have been sent in a 200 281 response to the same request 283 If the 206 response is the result of an If-Range request, the 284 response SHOULD NOT include other representation header fields. 285 Otherwise, the response MUST include all of the representation header 286 fields that would have been returned with a 200 (OK) response to the 287 same request. 289 A cache MUST NOT combine a 206 response with other previously cached 290 content if the ETag or Last-Modified header fields do not match 291 exactly, see Section 4. 293 A cache that does not support the Range and Content-Range header 294 fields MUST NOT cache 206 (Partial Content) responses. Furthermore, 295 if a response uses a range unit that is not understood by the cache, 296 then it MUST NOT be cached either. 298 3.2. 416 Requested Range Not Satisfiable 300 A server SHOULD return a response with this status code if a request 301 included a Range header field (Section 5.4), and none of the ranges- 302 specifier values in this field overlap the current extent of the 303 selected resource, and the request did not include an If-Range header 304 field (Section 5.3). (For byte-ranges, this means that the first- 305 byte-pos of all of the byte-range-spec values were greater than the 306 current length of the selected resource.) 308 When this status code is returned for a byte-range request, the 309 response SHOULD include a Content-Range header field specifying the 310 current length of the representation (see Section 5.2). This 311 response MUST NOT use the multipart/byteranges content-type. 313 4. Combining Ranges 315 A response might transfer only a subrange of a representation, either 316 because the request included one or more Range specifications, or 317 because a connection closed prematurely. After several such 318 transfers, a cache might have received several ranges of the same 319 representation. 321 If a cache has a stored non-empty set of subranges for a 322 representation, and an incoming response transfers another subrange, 323 the cache MAY combine the new subrange with the existing set if both 324 the following conditions are met: 326 o Both the incoming response and the cache entry have a cache 327 validator. 329 o The two cache validators match using the strong comparison 330 function (see Section 2.2.2 of [Part4]). 332 If either requirement is not met, the cache MUST use only the most 333 recent partial response (based on the Date values transmitted with 334 every response, and using the incoming response if these values are 335 equal or missing), and MUST discard the other partial information. 337 5. Header Field Definitions 339 This section defines the syntax and semantics of HTTP/1.1 header 340 fields related to range requests and partial responses. 342 5.1. Accept-Ranges 344 The "Accept-Ranges" header field allows a resource to indicate its 345 acceptance of range requests. 347 Accept-Ranges = acceptable-ranges 348 acceptable-ranges = 1#range-unit / "none" 350 Origin servers that accept byte-range requests MAY send 352 Accept-Ranges: bytes 354 but are not required to do so. Clients MAY generate range requests 355 without having received this header field for the resource involved. 356 Range units are defined in Section 2. 358 Servers that do not accept any kind of range request for a resource 359 MAY send 361 Accept-Ranges: none 363 to advise the client not to attempt a range request. 365 5.2. Content-Range 367 The "Content-Range" header field is sent with a partial 368 representation to specify where in the full representation the 369 payload body is intended to be applied. 371 Range units are defined in Section 2. 373 Content-Range = content-range-spec 375 content-range-spec = byte-content-range-spec 376 / other-content-range-spec 377 byte-content-range-spec = bytes-unit SP 378 byte-range-resp-spec "/" 379 ( instance-length / "*" ) 381 byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) 382 / "*" 384 instance-length = 1*DIGIT 386 other-content-range-spec = other-range-unit SP 387 other-range-resp-spec 388 other-range-resp-spec = *CHAR 390 The header field SHOULD indicate the total length of the full 391 representation, unless this length is unknown or difficult to 392 determine. The asterisk "*" character means that the instance-length 393 is unknown at the time when the response was generated. 395 Unlike byte-ranges-specifier values (see Section 5.4.1), a byte- 396 range-resp-spec MUST only specify one range, and MUST contain 397 absolute byte positions for both the first and last byte of the 398 range. 400 A byte-content-range-spec with a byte-range-resp-spec whose last- 401 byte-pos value is less than its first-byte-pos value, or whose 402 instance-length value is less than or equal to its last-byte-pos 403 value, is invalid. The recipient of an invalid byte-content-range- 404 spec MUST ignore it and any content transferred along with it. 406 In the case of a byte range request: A server sending a response with 407 status code 416 (Requested range not satisfiable) SHOULD include a 408 Content-Range field with a byte-range-resp-spec of "*". The 409 instance-length specifies the current length of the selected 410 resource. A response with status code 206 (Partial Content) MUST NOT 411 include a Content-Range field with a byte-range-resp-spec of "*". 413 Examples of byte-content-range-spec values, assuming that the 414 representation contains a total of 1234 bytes: 416 o The first 500 bytes: 418 bytes 0-499/1234 420 o The second 500 bytes: 422 bytes 500-999/1234 424 o All except for the first 500 bytes: 426 bytes 500-1233/1234 428 o The last 500 bytes: 430 bytes 734-1233/1234 432 When an HTTP message includes the content of a single range (for 433 example, a response to a request for a single range, or to a request 434 for a set of ranges that overlap without any holes), this content is 435 transmitted with a Content-Range header field, and a Content-Length 436 header field showing the number of bytes actually transferred. For 437 example, 438 HTTP/1.1 206 Partial Content 439 Date: Wed, 15 Nov 1995 06:25:24 GMT 440 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 441 Content-Range: bytes 21010-47021/47022 442 Content-Length: 26012 443 Content-Type: image/gif 445 When an HTTP message includes the content of multiple ranges (for 446 example, a response to a request for multiple non-overlapping 447 ranges), these are transmitted as a multipart message. The multipart 448 media type used for this purpose is "multipart/byteranges" as defined 449 in Appendix A. 451 A response to a request for a single range MUST NOT be sent using the 452 multipart/byteranges media type. A response to a request for 453 multiple ranges, whose result is a single range, MAY be sent as a 454 multipart/byteranges media type with one part. A client that cannot 455 decode a multipart/byteranges message MUST NOT ask for multiple 456 ranges in a single request. 458 When a client requests multiple ranges in one request, the server 459 SHOULD return them in the order that they appeared in the request. 461 If the server ignores a byte-range-spec because it is syntactically 462 invalid, the server SHOULD treat the request as if the invalid Range 463 header field did not exist. (Normally, this means return a 200 464 response containing the full representation). 466 If the server receives a request (other than one including an If- 467 Range header field) with an unsatisfiable Range header field (that 468 is, all of whose byte-range-spec values have a first-byte-pos value 469 greater than the current length of the selected resource), it SHOULD 470 return a response code of 416 (Requested range not satisfiable) 471 (Section 3.2). 473 Note: Clients cannot depend on servers to send a 416 (Requested 474 range not satisfiable) response instead of a 200 (OK) response for 475 an unsatisfiable Range header field, since not all servers 476 implement this header field. 478 5.3. If-Range 480 If a client has a partial copy of a representation in its cache, and 481 wishes to have an up-to-date copy of the entire representation in its 482 cache, it could use the Range header field with a conditional GET 483 (using either or both of If-Unmodified-Since and If-Match.) However, 484 if the condition fails because the representation has been modified, 485 the client would then have to make a second request to obtain the 486 entire current representation. 488 The "If-Range" header field allows a client to "short-circuit" the 489 second request. Informally, its meaning is "if the representation is 490 unchanged, send me the part(s) that I am missing; otherwise, send me 491 the entire new representation". 493 If-Range = entity-tag / HTTP-date 495 Only a strong validator (Section 2.2.2 of [Part4]) is usable for 496 range retrieval, since otherwise the client might end up with an 497 internally inconsistent representation. Clients MUST NOT use weak 498 validators in range requests. A cache or origin server receiving a 499 conditional range request MUST use the strong comparison function to 500 evaluate the condition. 502 If the client has no entity-tag for a representation, but does have a 503 Last-Modified date, it MAY use that date in an If-Range header field. 504 (The server can distinguish between a valid HTTP-date and any form of 505 entity-tag by examining no more than two characters.) The If-Range 506 header field SHOULD only be used together with a Range header field, 507 and MUST be ignored if the request does not include a Range header 508 field, or if the server does not support the sub-range operation. 510 If a client wishes to perform a sub-range retrieval on a value for 511 which it has only a Last-Modified time and no opaque validator, it 512 MAY do this only if the Last-Modified time is strong in the sense 513 described in Section 2.1.2 of [Part4]. 515 If the entity-tag given in the If-Range header field matches the 516 current cache validator for the representation, then the server 517 SHOULD provide the specified sub-range of the representation using a 518 206 (Partial Content) response. If the cache validator does not 519 match, then the server SHOULD return the entire representation using 520 a 200 (OK) response. 522 5.4. Range 524 5.4.1. Byte Ranges 526 Since all HTTP representations are transferred as sequences of bytes, 527 the concept of a byte range is meaningful for any HTTP 528 representation. (However, not all clients and servers need to 529 support byte-range operations.) 531 Byte range specifications in HTTP apply to the sequence of bytes in 532 the representation body (not necessarily the same as the message- 533 body). 535 A byte range operation MAY specify a single range of bytes, or a set 536 of ranges within a single representation. 538 byte-ranges-specifier = bytes-unit "=" byte-range-set 539 byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec ) 540 byte-range-spec = first-byte-pos "-" [ last-byte-pos ] 541 first-byte-pos = 1*DIGIT 542 last-byte-pos = 1*DIGIT 544 The first-byte-pos value in a byte-range-spec gives the byte-offset 545 of the first byte in a range. The last-byte-pos value gives the 546 byte-offset of the last byte in the range; that is, the byte 547 positions specified are inclusive. Byte offsets start at zero. 549 If the last-byte-pos value is present, it MUST be greater than or 550 equal to the first-byte-pos in that byte-range-spec, or the byte- 551 range-spec is syntactically invalid. The recipient of a byte-range- 552 set that includes one or more syntactically invalid byte-range-spec 553 values MUST ignore the header field that includes that byte-range- 554 set. 556 If the last-byte-pos value is absent, or if the value is greater than 557 or equal to the current length of the representation body, last-byte- 558 pos is taken to be equal to one less than the current length of the 559 representation in bytes. 561 By its choice of last-byte-pos, a client can limit the number of 562 bytes retrieved without knowing the size of the representation. 564 suffix-byte-range-spec = "-" suffix-length 565 suffix-length = 1*DIGIT 567 A suffix-byte-range-spec is used to specify the suffix of the 568 representation body, of a length given by the suffix-length value. 569 (That is, this form specifies the last N bytes of a representation.) 570 If the representation is shorter than the specified suffix-length, 571 the entire representation is used. 573 If a syntactically valid byte-range-set includes at least one byte- 574 range-spec whose first-byte-pos is less than the current length of 575 the representation, or at least one suffix-byte-range-spec with a 576 non-zero suffix-length, then the byte-range-set is satisfiable. 577 Otherwise, the byte-range-set is unsatisfiable. If the byte-range- 578 set is unsatisfiable, the server SHOULD return a response with a 416 579 (Requested range not satisfiable) status code. Otherwise, the server 580 SHOULD return a response with a 206 (Partial Content) status code 581 containing the satisfiable ranges of the representation. 583 Examples of byte-ranges-specifier values (assuming a representation 584 of length 10000): 586 o The first 500 bytes (byte offsets 0-499, inclusive): 588 bytes=0-499 590 o The second 500 bytes (byte offsets 500-999, inclusive): 592 bytes=500-999 594 o The final 500 bytes (byte offsets 9500-9999, inclusive): 596 bytes=-500 598 Or: 600 bytes=9500- 602 o The first and last bytes only (bytes 0 and 9999): 604 bytes=0-0,-1 606 o Several legal but not canonical specifications of the second 500 607 bytes (byte offsets 500-999, inclusive): 609 bytes=500-600,601-999 610 bytes=500-700,601-999 612 5.4.2. Range Retrieval Requests 614 The "Range" header field defines the GET method (conditional or not) 615 to request one or more sub-ranges of the response representation 616 body, instead of the entire representation body. 618 Range = byte-ranges-specifier / other-ranges-specifier 619 other-ranges-specifier = other-range-unit "=" other-range-set 620 other-range-set = 1*CHAR 622 A server MAY ignore the Range header field. However, HTTP/1.1 origin 623 servers and intermediate caches ought to support byte ranges when 624 possible, since Range supports efficient recovery from partially 625 failed transfers, and supports efficient partial retrieval of large 626 representations. 628 If the server supports the Range header field and the specified range 629 or ranges are appropriate for the representation: 631 o The presence of a Range header field in an unconditional GET 632 modifies what is returned if the GET is otherwise successful. In 633 other words, the response carries a status code of 206 (Partial 634 Content) instead of 200 (OK). 636 o The presence of a Range header field in a conditional GET (a 637 request using one or both of If-Modified-Since and If-None-Match, 638 or one or both of If-Unmodified-Since and If-Match) modifies what 639 is returned if the GET is otherwise successful and the condition 640 is true. It does not affect the 304 (Not Modified) response 641 returned if the conditional is false. 643 In some cases, it might be more appropriate to use the If-Range 644 header field (see Section 5.3) in addition to the Range header field. 646 If a proxy that supports ranges receives a Range request, forwards 647 the request to an inbound server, and receives an entire 648 representation in reply, it MAY only return the requested range to 649 its client. 651 6. IANA Considerations 653 6.1. Status Code Registration 655 The HTTP Status Code Registry located at 656 shall be updated 657 with the registrations below: 659 +-------+---------------------------------+-------------+ 660 | Value | Description | Reference | 661 +-------+---------------------------------+-------------+ 662 | 206 | Partial Content | Section 3.1 | 663 | 416 | Requested Range Not Satisfiable | Section 3.2 | 664 +-------+---------------------------------+-------------+ 666 6.2. Header Field Registration 668 The Message Header Field Registry located at shall be 670 updated with the permanent registrations below (see [RFC3864]): 672 +-------------------+----------+----------+-------------+ 673 | Header Field Name | Protocol | Status | Reference | 674 +-------------------+----------+----------+-------------+ 675 | Accept-Ranges | http | standard | Section 5.1 | 676 | Content-Range | http | standard | Section 5.2 | 677 | If-Range | http | standard | Section 5.3 | 678 | Range | http | standard | Section 5.4 | 679 +-------------------+----------+----------+-------------+ 681 The change controller is: "IETF (iesg@ietf.org) - Internet 682 Engineering Task Force". 684 6.3. Range Specifier Registration 686 The registration procedure for HTTP Range Specifiers is defined by 687 Section 2.1 of this document. 689 The HTTP Range Specifier Registry shall be created at 690 and be 691 populated with the registrations below: 693 +----------------------+-------------------+----------------------+ 694 | Range Specifier Name | Description | Reference | 695 +----------------------+-------------------+----------------------+ 696 | bytes | a range of octets | (this specification) | 697 +----------------------+-------------------+----------------------+ 699 The change controller is: "IETF (iesg@ietf.org) - Internet 700 Engineering Task Force". 702 7. Security Considerations 704 No additional security considerations have been identified beyond 705 those applicable to HTTP in general [Part1]. 707 8. Acknowledgments 709 Most of the specification of ranges is based on work originally done 710 by Ari Luotonen and John Franks, with additional input from Steve 711 Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin 712 Hamilton, Koen Holtman, Shel Kaplan, Paul Leach, Alex Lopez-Ortiz, 713 Larry Masinter, Jeff Mogul, Lou Montulli, David W. Morris, Luigi 714 Rizzo, and Bill Weihl. 716 9. References 717 9.1. Normative References 719 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 720 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 721 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, 722 and Message Parsing", draft-ietf-httpbis-p1-messaging-15 723 (work in progress), July 2011. 725 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 726 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 727 and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional 728 Requests", draft-ietf-httpbis-p4-conditional-15 (work in 729 progress), July 2011. 731 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 732 Extensions (MIME) Part Two: Media Types", RFC 2046, 733 November 1996. 735 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 736 Requirement Levels", BCP 14, RFC 2119, March 1997. 738 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 739 Specifications: ABNF", STD 68, RFC 5234, January 2008. 741 9.2. Informative References 743 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 744 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 745 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 747 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 748 Procedures for Message Header Fields", BCP 90, RFC 3864, 749 September 2004. 751 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 752 Registration Procedures", BCP 13, RFC 4288, December 2005. 754 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 755 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 756 May 2008. 758 Appendix A. Internet Media Type multipart/byteranges 760 When an HTTP 206 (Partial Content) response message includes the 761 content of multiple ranges (a response to a request for multiple non- 762 overlapping ranges), these are transmitted as a multipart message- 763 body ([RFC2046], Section 5.1). The media type for this purpose is 764 called "multipart/byteranges". The following is to be registered 765 with IANA [RFC4288]. 767 Note: Despite the name "multipart/byteranges" is not limited to 768 the byte ranges only. 770 The multipart/byteranges media type includes one or more parts, each 771 with its own Content-Type and Content-Range fields. The required 772 boundary parameter specifies the boundary string used to separate 773 each body-part. 775 Type name: multipart 777 Subtype name: byteranges 779 Required parameters: boundary 781 Optional parameters: none 783 Encoding considerations: only "7bit", "8bit", or "binary" are 784 permitted 786 Security considerations: none 788 Interoperability considerations: none 790 Published specification: This specification (see Appendix A). 792 Applications that use this media type: 794 Additional information: 796 Magic number(s): none 798 File extension(s): none 800 Macintosh file type code(s): none 802 Person and email address to contact for further information: See 803 Authors Section. 805 Intended usage: COMMON 807 Restrictions on usage: none 809 Author/Change controller: IESG 810 For example: 812 HTTP/1.1 206 Partial Content 813 Date: Wed, 15 Nov 1995 06:25:24 GMT 814 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 815 Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES 817 --THIS_STRING_SEPARATES 818 Content-type: application/pdf 819 Content-range: bytes 500-999/8000 821 ...the first range... 822 --THIS_STRING_SEPARATES 823 Content-type: application/pdf 824 Content-range: bytes 7000-7999/8000 826 ...the second range 827 --THIS_STRING_SEPARATES-- 829 Other example: 831 HTTP/1.1 206 Partial Content 832 Date: Tue, 14 Nov 1995 06:25:24 GMT 833 Last-Modified: Tue, 14 July 04:58:08 GMT 834 Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES 836 --THIS_STRING_SEPARATES 837 Content-type: video/example 838 Content-range: exampleunit 1.2-4.3/25 840 ...the first range... 841 --THIS_STRING_SEPARATES 842 Content-type: video/example 843 Content-range: exampleunit 11.2-14.3/25 845 ...the second range 846 --THIS_STRING_SEPARATES-- 848 Notes: 850 1. Additional CRLFs MAY precede the first boundary string in the 851 body. 853 2. Although [RFC2046] permits the boundary string to be quoted, some 854 existing implementations handle a quoted boundary string 855 incorrectly. 857 3. A number of browsers and servers were coded to an early draft of 858 the byteranges specification to use a media type of multipart/ 859 x-byteranges, which is almost, but not quite compatible with the 860 version documented in HTTP/1.1. 862 Appendix B. Compatibility with Previous Versions 864 B.1. Changes from RFC 2616 866 Clarify that it is not ok to use a weak cache validator in a 206 867 response. (Section 3.1) 869 Change ABNF productions for header fields to only define the field 870 value. (Section 5) 872 Clarify that multipart/byteranges can consist of a single part. 873 (Appendix A) 875 Appendix C. Collected ABNF 876 Accept-Ranges = acceptable-ranges 878 Content-Range = content-range-spec 880 HTTP-date = 882 If-Range = entity-tag / HTTP-date 884 OWS = 886 Range = byte-ranges-specifier / other-ranges-specifier 888 acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS 889 range-unit ] ) ) / "none" 891 byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" ( 892 instance-length / "*" ) 893 byte-range-resp-spec = ( first-byte-pos "-" last-byte-pos ) / "*" 894 byte-range-set = ( *( "," OWS ) byte-range-spec ) / ( 895 suffix-byte-range-spec *( OWS "," [ ( OWS byte-range-spec ) / 896 suffix-byte-range-spec ] ) ) 897 byte-range-spec = first-byte-pos "-" [ last-byte-pos ] 898 byte-ranges-specifier = bytes-unit "=" byte-range-set 899 bytes-unit = "bytes" 901 content-range-spec = byte-content-range-spec / 902 other-content-range-spec 904 entity-tag = 906 first-byte-pos = 1*DIGIT 908 instance-length = 1*DIGIT 910 last-byte-pos = 1*DIGIT 912 other-content-range-spec = other-range-unit SP other-range-resp-spec 913 other-range-resp-spec = *CHAR 914 other-range-set = 1*CHAR 915 other-range-unit = token 916 other-ranges-specifier = other-range-unit "=" other-range-set 918 range-unit = bytes-unit / other-range-unit 920 suffix-byte-range-spec = "-" suffix-length 921 suffix-length = 1*DIGIT 923 token = 924 ABNF diagnostics: 926 ; Accept-Ranges defined but not used 927 ; Content-Range defined but not used 928 ; If-Range defined but not used 929 ; Range defined but not used 931 Appendix D. Change Log (to be removed by RFC Editor before publication) 933 D.1. Since RFC 2616 935 Extracted relevant partitions from [RFC2616]. 937 D.2. Since draft-ietf-httpbis-p5-range-00 939 Closed issues: 941 o : "Cache 942 validators in 206 responses" 943 () 945 o : "Normative and 946 Informative references" 948 o : "Normative up- 949 to-date references" 951 D.3. Since draft-ietf-httpbis-p5-range-01 953 Closed issues: 955 o : "Updating to 956 RFC4288" 958 Ongoing work on ABNF conversion 959 (): 961 o Add explicit references to BNF syntax and rules imported from 962 other parts of the specification. 964 D.4. Since draft-ietf-httpbis-p5-range-02 966 Ongoing work on IANA Message Header Field Registration 967 (): 969 o Reference RFC 3984, and update header field registrations for 970 headers defined in this document. 972 D.5. Since draft-ietf-httpbis-p5-range-03 974 None. 976 D.6. Since draft-ietf-httpbis-p5-range-04 978 Closed issues: 980 o : "multipart/ 981 byteranges minimum number of parts" 983 Ongoing work on ABNF conversion 984 (): 986 o Use "/" instead of "|" for alternatives. 988 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 989 whitespace ("OWS") and required whitespace ("RWS"). 991 o Rewrite ABNFs to spell out whitespace rules, factor out header 992 field value format definitions. 994 D.7. Since draft-ietf-httpbis-p5-range-05 996 Closed issues: 998 o : "State base 999 for *-byte-pos and suffix-length" 1001 Ongoing work on Custom Ranges 1002 (): 1004 o Remove bias in favor of byte ranges; allow custom ranges in ABNF. 1006 Final work on ABNF conversion 1007 (): 1009 o Add appendix containing collected and expanded ABNF, reorganize 1010 ABNF introduction. 1012 D.8. Since draft-ietf-httpbis-p5-range-06 1014 Closed issues: 1016 o : "base for 1017 numeric protocol elements" 1019 D.9. Since draft-ietf-httpbis-p5-range-07 1021 Closed issues: 1023 o Fixed discrepancy in the If-Range definition about allowed 1024 validators. 1026 o : "multipart/ 1027 byteranges for custom range units" 1029 o : "range unit 1030 missing from other-ranges-specifier in Range header" 1032 o : "move IANA 1033 registrations for optional status codes" 1035 D.10. Since draft-ietf-httpbis-p5-range-08 1037 No significant changes. 1039 D.11. Since draft-ietf-httpbis-p5-range-09 1041 No significant changes. 1043 D.12. Since draft-ietf-httpbis-p5-range-10 1045 Closed issues: 1047 o : "Clarify 1048 'Requested Variant'" 1050 o : "Clarify 1051 entity / representation / variant terminology" 1053 o : "consider 1054 removing the 'changes from 2068' sections" 1056 Ongoing work on Custom Ranges 1057 (): 1059 o Add IANA registry. 1061 D.13. Since draft-ietf-httpbis-p5-range-11 1063 Closed issues: 1065 o : "Caches can't 1066 be required to serve ranges" 1068 D.14. Since draft-ietf-httpbis-p5-range-12 1070 Closed issues: 1072 o : "Header 1073 Classification" 1075 D.15. Since draft-ietf-httpbis-p5-range-13 1077 Closed issues: 1079 o : "untangle 1080 ABNFs for header fields" 1082 D.16. Since draft-ietf-httpbis-p5-range-14 1084 None. 1086 Index 1088 2 1089 206 Partial Content (status code) 7 1091 4 1092 416 Requested Range Not Satisfiable (status code) 8 1094 A 1095 Accept-Ranges header field 9 1097 C 1098 Content-Range header field 9 1100 G 1101 Grammar 1102 Accept-Ranges 9 1103 acceptable-ranges 9 1104 byte-content-range-spec 9 1105 byte-range-resp-spec 9 1106 byte-range-set 13 1107 byte-range-spec 13 1108 byte-ranges-specifier 13 1109 bytes-unit 6 1110 Content-Range 9 1111 content-range-spec 9 1112 first-byte-pos 13 1113 If-Range 12 1114 instance-length 9 1115 last-byte-pos 13 1116 other-range-unit 6 1117 Range 14 1118 range-unit 6 1119 ranges-specifier 13 1120 suffix-byte-range-spec 13 1121 suffix-length 13 1123 H 1124 Header Fields 1125 Accept-Ranges 9 1126 Content-Range 9 1127 If-Range 11 1128 Range 12 1130 I 1131 If-Range header field 11 1133 M 1134 Media Type 1135 multipart/byteranges 17 1136 multipart/x-byteranges 20 1137 multipart/byteranges Media Type 17 1138 multipart/x-byteranges Media Type 20 1140 R 1141 Range header field 12 1143 S 1144 Status Codes 1145 206 Partial Content 7 1146 416 Requested Range Not Satisfiable 8 1148 Authors' Addresses 1150 Roy T. Fielding (editor) 1151 Adobe Systems Incorporated 1152 345 Park Ave 1153 San Jose, CA 95110 1154 USA 1156 EMail: fielding@gbiv.com 1157 URI: http://roy.gbiv.com/ 1158 Jim Gettys 1159 Alcatel-Lucent Bell Labs 1160 21 Oak Knoll Road 1161 Carlisle, MA 01741 1162 USA 1164 EMail: jg@freedesktop.org 1165 URI: http://gettys.wordpress.com/ 1167 Jeffrey C. Mogul 1168 Hewlett-Packard Company 1169 HP Labs, Large Scale Systems Group 1170 1501 Page Mill Road, MS 1177 1171 Palo Alto, CA 94304 1172 USA 1174 EMail: JeffMogul@acm.org 1176 Henrik Frystyk Nielsen 1177 Microsoft Corporation 1178 1 Microsoft Way 1179 Redmond, WA 98052 1180 USA 1182 EMail: henrikn@microsoft.com 1184 Larry Masinter 1185 Adobe Systems Incorporated 1186 345 Park Ave 1187 San Jose, CA 95110 1188 USA 1190 EMail: LMM@acm.org 1191 URI: http://larry.masinter.net/ 1193 Paul J. Leach 1194 Microsoft Corporation 1195 1 Microsoft Way 1196 Redmond, WA 98052 1198 EMail: paulle@microsoft.com 1199 Tim Berners-Lee 1200 World Wide Web Consortium 1201 MIT Computer Science and Artificial Intelligence Laboratory 1202 The Stata Center, Building 32 1203 32 Vassar Street 1204 Cambridge, MA 02139 1205 USA 1207 EMail: timbl@w3.org 1208 URI: http://www.w3.org/People/Berners-Lee/ 1210 Yves Lafon (editor) 1211 World Wide Web Consortium 1212 W3C / ERCIM 1213 2004, rte des Lucioles 1214 Sophia-Antipolis, AM 06902 1215 France 1217 EMail: ylafon@w3.org 1218 URI: http://www.raubacapeu.net/people/yves/ 1220 Julian F. Reschke (editor) 1221 greenbytes GmbH 1222 Hafenweg 16 1223 Muenster, NW 48155 1224 Germany 1226 Phone: +49 251 2807760 1227 Fax: +49 251 2807761 1228 EMail: julian.reschke@greenbytes.de 1229 URI: http://greenbytes.de/tech/webdav/