idnits 2.17.1 draft-ietf-httpbis-p5-range-14.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 (April 18, 2011) is 4757 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-14 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-14 -- 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: October 20, 2011 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 April 18, 2011 22 HTTP/1.1, part 5: Range Requests and Partial Responses 23 draft-ietf-httpbis-p5-range-14 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.15. 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 October 20, 2011. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 96 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 97 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 98 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5 99 1.2.2. ABNF Rules defined in other Parts of the 100 Specification . . . . . . . . . . . . . . . . . . . . 5 101 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 5 102 2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 5 103 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 6 104 3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 6 105 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 7 106 4. Combining Ranges . . . . . . . . . . . . . . . . . . . . . . . 7 107 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 7 108 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 8 109 5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 8 110 5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 10 111 5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 11 112 5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 11 113 5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 13 114 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 115 6.1. Status Code Registration . . . . . . . . . . . . . . . . . 14 116 6.2. Header Field Registration . . . . . . . . . . . . . . . . 14 117 6.3. Range Specifier Registration . . . . . . . . . . . . . . . 15 118 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 119 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 120 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 121 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 122 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 123 Appendix A. Internet Media Type multipart/byteranges . . . . . . 16 124 Appendix B. Compatibility with Previous Versions . . . . . . . . 19 125 B.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 19 126 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 19 127 Appendix D. Change Log (to be removed by RFC Editor before 128 publication) . . . . . . . . . . . . . . . . . . . . 21 129 D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 21 130 D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 21 131 D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 21 132 D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 21 133 D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 22 134 D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 22 135 D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 22 136 D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 22 137 D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 23 138 D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 23 139 D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 23 140 D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 23 141 D.13. Since draft-ietf-httpbis-p5-range-11 . . . . . . . . . . . 23 142 D.14. Since draft-ietf-httpbis-p5-range-12 . . . . . . . . . . . 24 143 D.15. Since draft-ietf-httpbis-p5-range-13 . . . . . . . . . . . 24 144 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 146 1. Introduction 148 HTTP clients often encounter interrupted data transfers as a result 149 of cancelled requests or dropped connections. When a cache has 150 stored a partial representation, it is desirable to request the 151 remainder of that representation in a subsequent request rather than 152 transfer the entire representation. There are also a number of Web 153 applications that benefit from being able to request only a subset of 154 a larger representation, such as a single page of a very large 155 document or only part of an image to be rendered by a device with 156 limited local storage. 158 This document defines HTTP/1.1 range requests, partial responses, and 159 the multipart/byteranges media type. The protocol for range requests 160 is an OPTIONAL feature of HTTP, designed so resources or recipients 161 that do not implement this feature can respond as if it is a normal 162 GET request without impacting interoperability. Partial responses 163 are indicated by a distinct status code to not be mistaken for full 164 responses by intermediate caches that might not implement the 165 feature. 167 Although the HTTP range request mechanism is designed to allow for 168 extensible range types, this specification only defines requests for 169 byte ranges. 171 1.1. Requirements 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in [RFC2119]. 177 An implementation is not compliant if it fails to satisfy one or more 178 of the "MUST" or "REQUIRED" level requirements for the protocols it 179 implements. An implementation that satisfies all the "MUST" or 180 "REQUIRED" level and all the "SHOULD" level requirements for its 181 protocols is said to be "unconditionally compliant"; one that 182 satisfies all the "MUST" level requirements but not all the "SHOULD" 183 level requirements for its protocols is said to be "conditionally 184 compliant". 186 1.2. Syntax Notation 188 This specification uses the ABNF syntax defined in Section 1.2 of 189 [Part1] (which extends the syntax defined in [RFC5234] with a list 190 rule). Appendix C shows the collected ABNF, with the list rule 191 expanded. 193 The following core rules are included by reference, as defined in 195 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 196 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 197 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit 198 sequence of data), SP (space), VCHAR (any visible USASCII character), 199 and WSP (whitespace). 201 1.2.1. Core Rules 203 The core rules below are defined in Section 1.2.2 of [Part1]: 205 token = 206 OWS = 208 1.2.2. ABNF Rules defined in other Parts of the Specification 210 The ABNF rules below are defined in other parts: 212 HTTP-date = 214 entity-tag = 216 2. Range Units 218 HTTP/1.1 allows a client to request that only part (a range) of the 219 representation be included within the response. HTTP/1.1 uses range 220 units in the Range (Section 5.4) and Content-Range (Section 5.2) 221 header fields. A representation can be broken down into subranges 222 according to various structural units. 224 range-unit = bytes-unit / other-range-unit 225 bytes-unit = "bytes" 226 other-range-unit = token 228 HTTP/1.1 has been designed to allow implementations of applications 229 that do not depend on knowledge of ranges. The only range unit 230 defined by HTTP/1.1 is "bytes". Additional specifiers can be defined 231 as described in Section 2.1. 233 If a range unit is not understood in a request, a server MUST ignore 234 the whole Range header field (Section 5.4). If a range unit is not 235 understood in a response, an intermediary SHOULD pass the response to 236 the client; a client MUST fail. 238 2.1. Range Specifier Registry 240 The HTTP Range Specifier Registry defines the name space for the 241 range specifier names. 243 Registrations MUST include the following fields: 245 o Name 247 o Description 249 o Pointer to specification text 251 Values to be added to this name space are subject to IETF review 252 ([RFC5226], Section 4.1). 254 The registry itself is maintained at 255 . 257 3. Status Code Definitions 259 3.1. 206 Partial Content 261 The server has fulfilled the partial GET request for the resource. 262 The request MUST have included a Range header field (Section 5.4) 263 indicating the desired range, and MAY have included an If-Range 264 header field (Section 5.3) to make the request conditional. 266 The response MUST include the following header fields: 268 o Either a Content-Range header field (Section 5.2) indicating the 269 range included with this response, or a multipart/byteranges 270 Content-Type including Content-Range fields for each part. If a 271 Content-Length header field is present in the response, its value 272 MUST match the actual number of octets transmitted in the message- 273 body. 275 o Date 277 o Cache-Control, ETag, Expires, Content-Location, Last-Modified, 278 and/or Vary, if the header field would have been sent in a 200 279 response to the same request 281 If the 206 response is the result of an If-Range request, the 282 response SHOULD NOT include other representation header fields. 283 Otherwise, the response MUST include all of the representation header 284 fields that would have been returned with a 200 (OK) response to the 285 same request. 287 A cache MUST NOT combine a 206 response with other previously cached 288 content if the ETag or Last-Modified header fields do not match 289 exactly, see Section 4. 291 A cache that does not support the Range and Content-Range header 292 fields MUST NOT cache 206 (Partial Content) responses. Furthermore, 293 if a response uses a range unit that is not understood by the cache, 294 then it MUST NOT be cached either. 296 3.2. 416 Requested Range Not Satisfiable 298 A server SHOULD return a response with this status code if a request 299 included a Range header field (Section 5.4), and none of the ranges- 300 specifier values in this field overlap the current extent of the 301 selected resource, and the request did not include an If-Range header 302 field (Section 5.3). (For byte-ranges, this means that the first- 303 byte-pos of all of the byte-range-spec values were greater than the 304 current length of the selected resource.) 306 When this status code is returned for a byte-range request, the 307 response SHOULD include a Content-Range header field specifying the 308 current length of the representation (see Section 5.2). This 309 response MUST NOT use the multipart/byteranges content-type. 311 4. Combining Ranges 313 A response might transfer only a subrange of a representation, either 314 because the request included one or more Range specifications, or 315 because a connection closed prematurely. After several such 316 transfers, a cache might have received several ranges of the same 317 representation. 319 If a cache has a stored non-empty set of subranges for a 320 representation, and an incoming response transfers another subrange, 321 the cache MAY combine the new subrange with the existing set if both 322 the following conditions are met: 324 o Both the incoming response and the cache entry have a cache 325 validator. 327 o The two cache validators match using the strong comparison 328 function (see Section 2.2.2 of [Part4]). 330 If either requirement is not met, the cache MUST use only the most 331 recent partial response (based on the Date values transmitted with 332 every response, and using the incoming response if these values are 333 equal or missing), and MUST discard the other partial information. 335 5. Header Field Definitions 337 This section defines the syntax and semantics of HTTP/1.1 header 338 fields related to range requests and partial responses. 340 5.1. Accept-Ranges 342 The "Accept-Ranges" header field allows a resource to indicate its 343 acceptance of range requests. 345 Accept-Ranges = acceptable-ranges 346 acceptable-ranges = 1#range-unit / "none" 348 Origin servers that accept byte-range requests MAY send 350 Accept-Ranges: bytes 352 but are not required to do so. Clients MAY generate range requests 353 without having received this header field for the resource involved. 354 Range units are defined in Section 2. 356 Servers that do not accept any kind of range request for a resource 357 MAY send 359 Accept-Ranges: none 361 to advise the client not to attempt a range request. 363 5.2. Content-Range 365 The "Content-Range" header field is sent with a partial 366 representation to specify where in the full representation the 367 payload body is intended to be applied. 369 Range units are defined in Section 2. 371 Content-Range = content-range-spec 373 content-range-spec = byte-content-range-spec 374 / other-content-range-spec 375 byte-content-range-spec = bytes-unit SP 376 byte-range-resp-spec "/" 377 ( instance-length / "*" ) 379 byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) 380 / "*" 382 instance-length = 1*DIGIT 384 other-content-range-spec = other-range-unit SP 385 other-range-resp-spec 386 other-range-resp-spec = *CHAR 388 The header field SHOULD indicate the total length of the full 389 representation, unless this length is unknown or difficult to 390 determine. The asterisk "*" character means that the instance-length 391 is unknown at the time when the response was generated. 393 Unlike byte-ranges-specifier values (see Section 5.4.1), a byte- 394 range-resp-spec MUST only specify one range, and MUST contain 395 absolute byte positions for both the first and last byte of the 396 range. 398 A byte-content-range-spec with a byte-range-resp-spec whose last- 399 byte-pos value is less than its first-byte-pos value, or whose 400 instance-length value is less than or equal to its last-byte-pos 401 value, is invalid. The recipient of an invalid byte-content-range- 402 spec MUST ignore it and any content transferred along with it. 404 In the case of a byte range request: A server sending a response with 405 status code 416 (Requested range not satisfiable) SHOULD include a 406 Content-Range field with a byte-range-resp-spec of "*". The 407 instance-length specifies the current length of the selected 408 resource. A response with status code 206 (Partial Content) MUST NOT 409 include a Content-Range field with a byte-range-resp-spec of "*". 411 Examples of byte-content-range-spec values, assuming that the 412 representation contains a total of 1234 bytes: 414 o The first 500 bytes: 416 bytes 0-499/1234 418 o The second 500 bytes: 420 bytes 500-999/1234 422 o All except for the first 500 bytes: 424 bytes 500-1233/1234 426 o The last 500 bytes: 428 bytes 734-1233/1234 430 When an HTTP message includes the content of a single range (for 431 example, a response to a request for a single range, or to a request 432 for a set of ranges that overlap without any holes), this content is 433 transmitted with a Content-Range header field, and a Content-Length 434 header field showing the number of bytes actually transferred. For 435 example, 436 HTTP/1.1 206 Partial Content 437 Date: Wed, 15 Nov 1995 06:25:24 GMT 438 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 439 Content-Range: bytes 21010-47021/47022 440 Content-Length: 26012 441 Content-Type: image/gif 443 When an HTTP message includes the content of multiple ranges (for 444 example, a response to a request for multiple non-overlapping 445 ranges), these are transmitted as a multipart message. The multipart 446 media type used for this purpose is "multipart/byteranges" as defined 447 in Appendix A. 449 A response to a request for a single range MUST NOT be sent using the 450 multipart/byteranges media type. A response to a request for 451 multiple ranges, whose result is a single range, MAY be sent as a 452 multipart/byteranges media type with one part. A client that cannot 453 decode a multipart/byteranges message MUST NOT ask for multiple 454 ranges in a single request. 456 When a client requests multiple ranges in one request, the server 457 SHOULD return them in the order that they appeared in the request. 459 If the server ignores a byte-range-spec because it is syntactically 460 invalid, the server SHOULD treat the request as if the invalid Range 461 header field did not exist. (Normally, this means return a 200 462 response containing the full representation). 464 If the server receives a request (other than one including an If- 465 Range header field) with an unsatisfiable Range header field (that 466 is, all of whose byte-range-spec values have a first-byte-pos value 467 greater than the current length of the selected resource), it SHOULD 468 return a response code of 416 (Requested range not satisfiable) 469 (Section 3.2). 471 Note: Clients cannot depend on servers to send a 416 (Requested 472 range not satisfiable) response instead of a 200 (OK) response for 473 an unsatisfiable Range header field, since not all servers 474 implement this header field. 476 5.3. If-Range 478 If a client has a partial copy of a representation in its cache, and 479 wishes to have an up-to-date copy of the entire representation in its 480 cache, it could use the Range header field with a conditional GET 481 (using either or both of If-Unmodified-Since and If-Match.) However, 482 if the condition fails because the representation has been modified, 483 the client would then have to make a second request to obtain the 484 entire current representation. 486 The "If-Range" header field allows a client to "short-circuit" the 487 second request. Informally, its meaning is "if the representation is 488 unchanged, send me the part(s) that I am missing; otherwise, send me 489 the entire new representation". 491 If-Range = entity-tag / HTTP-date 493 Only a strong validator (Section 2.2.2 of [Part4]) is usable for 494 range retrieval, since otherwise the client might end up with an 495 internally inconsistent representation. Clients MUST NOT use weak 496 validators in range requests. A cache or origin server receiving a 497 conditional range request MUST use the strong comparison function to 498 evaluate the condition. 500 If the client has no entity-tag for a representation, but does have a 501 Last-Modified date, it MAY use that date in an If-Range header field. 502 (The server can distinguish between a valid HTTP-date and any form of 503 entity-tag by examining no more than two characters.) The If-Range 504 header field SHOULD only be used together with a Range header field, 505 and MUST be ignored if the request does not include a Range header 506 field, or if the server does not support the sub-range operation. 508 If a client wishes to perform a sub-range retrieval on a value for 509 which it has only a Last-Modified time and no opaque validator, it 510 MAY do this only if the Last-Modified time is strong in the sense 511 described in Section 2.1.2 of [Part4]. 513 If the entity-tag given in the If-Range header field matches the 514 current cache validator for the representation, then the server 515 SHOULD provide the specified sub-range of the representation using a 516 206 (Partial Content) response. If the cache validator does not 517 match, then the server SHOULD return the entire representation using 518 a 200 (OK) response. 520 5.4. Range 522 5.4.1. Byte Ranges 524 Since all HTTP representations are transferred as sequences of bytes, 525 the concept of a byte range is meaningful for any HTTP 526 representation. (However, not all clients and servers need to 527 support byte-range operations.) 529 Byte range specifications in HTTP apply to the sequence of bytes in 530 the representation body (not necessarily the same as the message- 531 body). 533 A byte range operation MAY specify a single range of bytes, or a set 534 of ranges within a single representation. 536 byte-ranges-specifier = bytes-unit "=" byte-range-set 537 byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec ) 538 byte-range-spec = first-byte-pos "-" [ last-byte-pos ] 539 first-byte-pos = 1*DIGIT 540 last-byte-pos = 1*DIGIT 542 The first-byte-pos value in a byte-range-spec gives the byte-offset 543 of the first byte in a range. The last-byte-pos value gives the 544 byte-offset of the last byte in the range; that is, the byte 545 positions specified are inclusive. Byte offsets start at zero. 547 If the last-byte-pos value is present, it MUST be greater than or 548 equal to the first-byte-pos in that byte-range-spec, or the byte- 549 range-spec is syntactically invalid. The recipient of a byte-range- 550 set that includes one or more syntactically invalid byte-range-spec 551 values MUST ignore the header field that includes that byte-range- 552 set. 554 If the last-byte-pos value is absent, or if the value is greater than 555 or equal to the current length of the representation body, last-byte- 556 pos is taken to be equal to one less than the current length of the 557 representation in bytes. 559 By its choice of last-byte-pos, a client can limit the number of 560 bytes retrieved without knowing the size of the representation. 562 suffix-byte-range-spec = "-" suffix-length 563 suffix-length = 1*DIGIT 565 A suffix-byte-range-spec is used to specify the suffix of the 566 representation body, of a length given by the suffix-length value. 567 (That is, this form specifies the last N bytes of a representation.) 568 If the representation is shorter than the specified suffix-length, 569 the entire representation is used. 571 If a syntactically valid byte-range-set includes at least one byte- 572 range-spec whose first-byte-pos is less than the current length of 573 the representation, or at least one suffix-byte-range-spec with a 574 non-zero suffix-length, then the byte-range-set is satisfiable. 575 Otherwise, the byte-range-set is unsatisfiable. If the byte-range- 576 set is unsatisfiable, the server SHOULD return a response with a 416 577 (Requested range not satisfiable) status code. Otherwise, the server 578 SHOULD return a response with a 206 (Partial Content) status code 579 containing the satisfiable ranges of the representation. 581 Examples of byte-ranges-specifier values (assuming a representation 582 of length 10000): 584 o The first 500 bytes (byte offsets 0-499, inclusive): 586 bytes=0-499 588 o The second 500 bytes (byte offsets 500-999, inclusive): 590 bytes=500-999 592 o The final 500 bytes (byte offsets 9500-9999, inclusive): 594 bytes=-500 596 Or: 598 bytes=9500- 600 o The first and last bytes only (bytes 0 and 9999): 602 bytes=0-0,-1 604 o Several legal but not canonical specifications of the second 500 605 bytes (byte offsets 500-999, inclusive): 607 bytes=500-600,601-999 608 bytes=500-700,601-999 610 5.4.2. Range Retrieval Requests 612 The "Range" header field defines the GET method (conditional or not) 613 to request one or more sub-ranges of the response representation 614 body, instead of the entire representation body. 616 Range = byte-ranges-specifier / other-ranges-specifier 617 other-ranges-specifier = other-range-unit "=" other-range-set 618 other-range-set = 1*CHAR 620 A server MAY ignore the Range header field. However, HTTP/1.1 origin 621 servers and intermediate caches ought to support byte ranges when 622 possible, since Range supports efficient recovery from partially 623 failed transfers, and supports efficient partial retrieval of large 624 representations. 626 If the server supports the Range header field and the specified range 627 or ranges are appropriate for the representation: 629 o The presence of a Range header field in an unconditional GET 630 modifies what is returned if the GET is otherwise successful. In 631 other words, the response carries a status code of 206 (Partial 632 Content) instead of 200 (OK). 634 o The presence of a Range header field in a conditional GET (a 635 request using one or both of If-Modified-Since and If-None-Match, 636 or one or both of If-Unmodified-Since and If-Match) modifies what 637 is returned if the GET is otherwise successful and the condition 638 is true. It does not affect the 304 (Not Modified) response 639 returned if the conditional is false. 641 In some cases, it might be more appropriate to use the If-Range 642 header field (see Section 5.3) in addition to the Range header field. 644 If a proxy that supports ranges receives a Range request, forwards 645 the request to an inbound server, and receives an entire 646 representation in reply, it MAY only return the requested range to 647 its client. 649 6. IANA Considerations 651 6.1. Status Code Registration 653 The HTTP Status Code Registry located at 654 shall be updated 655 with the registrations below: 657 +-------+---------------------------------+-------------+ 658 | Value | Description | Reference | 659 +-------+---------------------------------+-------------+ 660 | 206 | Partial Content | Section 3.1 | 661 | 416 | Requested Range Not Satisfiable | Section 3.2 | 662 +-------+---------------------------------+-------------+ 664 6.2. Header Field Registration 666 The Message Header Field Registry located at shall be 668 updated with the permanent registrations below (see [RFC3864]): 670 +-------------------+----------+----------+-------------+ 671 | Header Field Name | Protocol | Status | Reference | 672 +-------------------+----------+----------+-------------+ 673 | Accept-Ranges | http | standard | Section 5.1 | 674 | Content-Range | http | standard | Section 5.2 | 675 | If-Range | http | standard | Section 5.3 | 676 | Range | http | standard | Section 5.4 | 677 +-------------------+----------+----------+-------------+ 679 The change controller is: "IETF (iesg@ietf.org) - Internet 680 Engineering Task Force". 682 6.3. Range Specifier Registration 684 The registration procedure for HTTP Range Specifiers is defined by 685 Section 2.1 of this document. 687 The HTTP Range Specifier Registry shall be created at 688 and be 689 populated with the registrations below: 691 +----------------------+-------------------+----------------------+ 692 | Range Specifier Name | Description | Reference | 693 +----------------------+-------------------+----------------------+ 694 | bytes | a range of octets | (this specification) | 695 +----------------------+-------------------+----------------------+ 697 The change controller is: "IETF (iesg@ietf.org) - Internet 698 Engineering Task Force". 700 7. Security Considerations 702 No additional security considerations have been identified beyond 703 those applicable to HTTP in general [Part1]. 705 8. Acknowledgments 707 Most of the specification of ranges is based on work originally done 708 by Ari Luotonen and John Franks, with additional input from Steve 709 Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin 710 Hamilton, Koen Holtman, Shel Kaplan, Paul Leach, Alex Lopez-Ortiz, 711 Larry Masinter, Jeff Mogul, Lou Montulli, David W. Morris, Luigi 712 Rizzo, and Bill Weihl. 714 9. References 715 9.1. Normative References 717 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 718 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 719 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, 720 and Message Parsing", draft-ietf-httpbis-p1-messaging-14 721 (work in progress), April 2011. 723 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 724 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 725 and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional 726 Requests", draft-ietf-httpbis-p4-conditional-14 (work in 727 progress), April 2011. 729 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 730 Extensions (MIME) Part Two: Media Types", RFC 2046, 731 November 1996. 733 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 734 Requirement Levels", BCP 14, RFC 2119, March 1997. 736 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 737 Specifications: ABNF", STD 68, RFC 5234, January 2008. 739 9.2. Informative References 741 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 742 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 743 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 745 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 746 Procedures for Message Header Fields", BCP 90, RFC 3864, 747 September 2004. 749 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 750 Registration Procedures", BCP 13, RFC 4288, December 2005. 752 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 753 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 754 May 2008. 756 Appendix A. Internet Media Type multipart/byteranges 758 When an HTTP 206 (Partial Content) response message includes the 759 content of multiple ranges (a response to a request for multiple non- 760 overlapping ranges), these are transmitted as a multipart message- 761 body ([RFC2046], Section 5.1). The media type for this purpose is 762 called "multipart/byteranges". The following is to be registered 763 with IANA [RFC4288]. 765 Note: Despite the name "multipart/byteranges" is not limited to 766 the byte ranges only. 768 The multipart/byteranges media type includes one or more parts, each 769 with its own Content-Type and Content-Range fields. The required 770 boundary parameter specifies the boundary string used to separate 771 each body-part. 773 Type name: multipart 775 Subtype name: byteranges 777 Required parameters: boundary 779 Optional parameters: none 781 Encoding considerations: only "7bit", "8bit", or "binary" are 782 permitted 784 Security considerations: none 786 Interoperability considerations: none 788 Published specification: This specification (see Appendix A). 790 Applications that use this media type: 792 Additional information: 794 Magic number(s): none 796 File extension(s): none 798 Macintosh file type code(s): none 800 Person and email address to contact for further information: See 801 Authors Section. 803 Intended usage: COMMON 805 Restrictions on usage: none 807 Author/Change controller: IESG 808 For example: 810 HTTP/1.1 206 Partial Content 811 Date: Wed, 15 Nov 1995 06:25:24 GMT 812 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 813 Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES 815 --THIS_STRING_SEPARATES 816 Content-type: application/pdf 817 Content-range: bytes 500-999/8000 819 ...the first range... 820 --THIS_STRING_SEPARATES 821 Content-type: application/pdf 822 Content-range: bytes 7000-7999/8000 824 ...the second range 825 --THIS_STRING_SEPARATES-- 827 Other example: 829 HTTP/1.1 206 Partial Content 830 Date: Tue, 14 Nov 1995 06:25:24 GMT 831 Last-Modified: Tue, 14 July 04:58:08 GMT 832 Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES 834 --THIS_STRING_SEPARATES 835 Content-type: video/example 836 Content-range: exampleunit 1.2-4.3/25 838 ...the first range... 839 --THIS_STRING_SEPARATES 840 Content-type: video/example 841 Content-range: exampleunit 11.2-14.3/25 843 ...the second range 844 --THIS_STRING_SEPARATES-- 846 Notes: 848 1. Additional CRLFs MAY precede the first boundary string in the 849 body. 851 2. Although [RFC2046] permits the boundary string to be quoted, some 852 existing implementations handle a quoted boundary string 853 incorrectly. 855 3. A number of browsers and servers were coded to an early draft of 856 the byteranges specification to use a media type of multipart/ 857 x-byteranges, which is almost, but not quite compatible with the 858 version documented in HTTP/1.1. 860 Appendix B. Compatibility with Previous Versions 862 B.1. Changes from RFC 2616 864 Clarify that it is not ok to use a weak cache validator in a 206 865 response. (Section 3.1) 867 Change ABNF productions for header fields to only define the field 868 value. (Section 5) 870 Clarify that multipart/byteranges can consist of a single part. 871 (Appendix A) 873 Appendix C. Collected ABNF 874 Accept-Ranges = acceptable-ranges 876 Content-Range = content-range-spec 878 HTTP-date = 880 If-Range = entity-tag / HTTP-date 882 OWS = 884 Range = byte-ranges-specifier / other-ranges-specifier 886 acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS 887 range-unit ] ) ) / "none" 889 byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" ( 890 instance-length / "*" ) 891 byte-range-resp-spec = ( first-byte-pos "-" last-byte-pos ) / "*" 892 byte-range-set = ( *( "," OWS ) byte-range-spec ) / ( 893 suffix-byte-range-spec *( OWS "," [ ( OWS byte-range-spec ) / 894 suffix-byte-range-spec ] ) ) 895 byte-range-spec = first-byte-pos "-" [ last-byte-pos ] 896 byte-ranges-specifier = bytes-unit "=" byte-range-set 897 bytes-unit = "bytes" 899 content-range-spec = byte-content-range-spec / 900 other-content-range-spec 902 entity-tag = 904 first-byte-pos = 1*DIGIT 906 instance-length = 1*DIGIT 908 last-byte-pos = 1*DIGIT 910 other-content-range-spec = other-range-unit SP other-range-resp-spec 911 other-range-resp-spec = *CHAR 912 other-range-set = 1*CHAR 913 other-range-unit = token 914 other-ranges-specifier = other-range-unit "=" other-range-set 916 range-unit = bytes-unit / other-range-unit 918 suffix-byte-range-spec = "-" suffix-length 919 suffix-length = 1*DIGIT 921 token = 922 ABNF diagnostics: 924 ; Accept-Ranges defined but not used 925 ; Content-Range defined but not used 926 ; If-Range defined but not used 927 ; Range defined but not used 929 Appendix D. Change Log (to be removed by RFC Editor before publication) 931 D.1. Since RFC 2616 933 Extracted relevant partitions from [RFC2616]. 935 D.2. Since draft-ietf-httpbis-p5-range-00 937 Closed issues: 939 o : "Cache 940 validators in 206 responses" 941 () 943 o : "Normative and 944 Informative references" 946 o : "Normative up- 947 to-date references" 949 D.3. Since draft-ietf-httpbis-p5-range-01 951 Closed issues: 953 o : "Updating to 954 RFC4288" 956 Ongoing work on ABNF conversion 957 (): 959 o Add explicit references to BNF syntax and rules imported from 960 other parts of the specification. 962 D.4. Since draft-ietf-httpbis-p5-range-02 964 Ongoing work on IANA Message Header Field Registration 965 (): 967 o Reference RFC 3984, and update header field registrations for 968 headers defined in this document. 970 D.5. Since draft-ietf-httpbis-p5-range-03 972 None. 974 D.6. Since draft-ietf-httpbis-p5-range-04 976 Closed issues: 978 o : "multipart/ 979 byteranges minimum number of parts" 981 Ongoing work on ABNF conversion 982 (): 984 o Use "/" instead of "|" for alternatives. 986 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 987 whitespace ("OWS") and required whitespace ("RWS"). 989 o Rewrite ABNFs to spell out whitespace rules, factor out header 990 field value format definitions. 992 D.7. Since draft-ietf-httpbis-p5-range-05 994 Closed issues: 996 o : "State base 997 for *-byte-pos and suffix-length" 999 Ongoing work on Custom Ranges 1000 (): 1002 o Remove bias in favor of byte ranges; allow custom ranges in ABNF. 1004 Final work on ABNF conversion 1005 (): 1007 o Add appendix containing collected and expanded ABNF, reorganize 1008 ABNF introduction. 1010 D.8. Since draft-ietf-httpbis-p5-range-06 1012 Closed issues: 1014 o : "base for 1015 numeric protocol elements" 1017 D.9. Since draft-ietf-httpbis-p5-range-07 1019 Closed issues: 1021 o Fixed discrepancy in the If-Range definition about allowed 1022 validators. 1024 o : "multipart/ 1025 byteranges for custom range units" 1027 o : "range unit 1028 missing from other-ranges-specifier in Range header" 1030 o : "move IANA 1031 registrations for optional status codes" 1033 D.10. Since draft-ietf-httpbis-p5-range-08 1035 No significant changes. 1037 D.11. Since draft-ietf-httpbis-p5-range-09 1039 No significant changes. 1041 D.12. Since draft-ietf-httpbis-p5-range-10 1043 Closed issues: 1045 o : "Clarify 1046 'Requested Variant'" 1048 o : "Clarify 1049 entity / representation / variant terminology" 1051 o : "consider 1052 removing the 'changes from 2068' sections" 1054 Ongoing work on Custom Ranges 1055 (): 1057 o Add IANA registry. 1059 D.13. Since draft-ietf-httpbis-p5-range-11 1061 Closed issues: 1063 o : "Caches can't 1064 be required to serve ranges" 1066 D.14. Since draft-ietf-httpbis-p5-range-12 1068 Closed issues: 1070 o : "Header 1071 Classification" 1073 D.15. Since draft-ietf-httpbis-p5-range-13 1075 Closed issues: 1077 o : "untangle 1078 ABNFs for header fields" 1080 Index 1082 2 1083 206 Partial Content (status code) 6 1085 4 1086 416 Requested Range Not Satisfiable (status code) 7 1088 A 1089 Accept-Ranges header field 8 1091 C 1092 Content-Range header field 8 1094 G 1095 Grammar 1096 Accept-Ranges 8 1097 acceptable-ranges 8 1098 byte-content-range-spec 8 1099 byte-range-resp-spec 8 1100 byte-range-set 12 1101 byte-range-spec 12 1102 byte-ranges-specifier 12 1103 bytes-unit 5 1104 Content-Range 8 1105 content-range-spec 8 1106 first-byte-pos 12 1107 If-Range 11 1108 instance-length 8 1109 last-byte-pos 12 1110 other-range-unit 5 1111 Range 13 1112 range-unit 5 1113 ranges-specifier 12 1114 suffix-byte-range-spec 12 1115 suffix-length 12 1117 H 1118 Header Fields 1119 Accept-Ranges 8 1120 Content-Range 8 1121 If-Range 10 1122 Range 11 1124 I 1125 If-Range header field 10 1127 M 1128 Media Type 1129 multipart/byteranges 16 1130 multipart/x-byteranges 19 1131 multipart/byteranges Media Type 16 1132 multipart/x-byteranges Media Type 19 1134 R 1135 Range header field 11 1137 S 1138 Status Codes 1139 206 Partial Content 6 1140 416 Requested Range Not Satisfiable 7 1142 Authors' Addresses 1144 Roy T. Fielding (editor) 1145 Adobe Systems Incorporated 1146 345 Park Ave 1147 San Jose, CA 95110 1148 USA 1150 EMail: fielding@gbiv.com 1151 URI: http://roy.gbiv.com/ 1152 Jim Gettys 1153 Alcatel-Lucent Bell Labs 1154 21 Oak Knoll Road 1155 Carlisle, MA 01741 1156 USA 1158 EMail: jg@freedesktop.org 1159 URI: http://gettys.wordpress.com/ 1161 Jeffrey C. Mogul 1162 Hewlett-Packard Company 1163 HP Labs, Large Scale Systems Group 1164 1501 Page Mill Road, MS 1177 1165 Palo Alto, CA 94304 1166 USA 1168 EMail: JeffMogul@acm.org 1170 Henrik Frystyk Nielsen 1171 Microsoft Corporation 1172 1 Microsoft Way 1173 Redmond, WA 98052 1174 USA 1176 EMail: henrikn@microsoft.com 1178 Larry Masinter 1179 Adobe Systems Incorporated 1180 345 Park Ave 1181 San Jose, CA 95110 1182 USA 1184 EMail: LMM@acm.org 1185 URI: http://larry.masinter.net/ 1187 Paul J. Leach 1188 Microsoft Corporation 1189 1 Microsoft Way 1190 Redmond, WA 98052 1192 EMail: paulle@microsoft.com 1193 Tim Berners-Lee 1194 World Wide Web Consortium 1195 MIT Computer Science and Artificial Intelligence Laboratory 1196 The Stata Center, Building 32 1197 32 Vassar Street 1198 Cambridge, MA 02139 1199 USA 1201 EMail: timbl@w3.org 1202 URI: http://www.w3.org/People/Berners-Lee/ 1204 Yves Lafon (editor) 1205 World Wide Web Consortium 1206 W3C / ERCIM 1207 2004, rte des Lucioles 1208 Sophia-Antipolis, AM 06902 1209 France 1211 EMail: ylafon@w3.org 1212 URI: http://www.raubacapeu.net/people/yves/ 1214 Julian F. Reschke (editor) 1215 greenbytes GmbH 1216 Hafenweg 16 1217 Muenster, NW 48155 1218 Germany 1220 Phone: +49 251 2807760 1221 Fax: +49 251 2807761 1222 EMail: julian.reschke@greenbytes.de 1223 URI: http://greenbytes.de/tech/webdav/