idnits 2.17.1 draft-ietf-httpbis-p5-range-11.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 (August 4, 2010) is 5014 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-11 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-11 -- 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 Day Software 4 Obsoletes: 2616 (if approved) J. Gettys 5 Intended status: Standards Track Alcatel-Lucent 6 Expires: February 5, 2011 J. Mogul 7 HP 8 H. Frystyk 9 Microsoft 10 L. Masinter 11 Adobe Systems 12 P. Leach 13 Microsoft 14 T. Berners-Lee 15 W3C/MIT 16 Y. Lafon, Ed. 17 W3C 18 J. Reschke, Ed. 19 greenbytes 20 August 4, 2010 22 HTTP/1.1, part 5: Range Requests and Partial Responses 23 draft-ietf-httpbis-p5-range-11 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). The current issues list is 40 at and related 41 documents (including fancy diffs) can be found at 42 . 44 The changes in this draft are summarized in Appendix D.12. 46 Status of This Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at http://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on February 5, 2011. 63 Copyright Notice 65 Copyright (c) 2010 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (http://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 This document may contain material from IETF Documents or IETF 79 Contributions published or made publicly available before November 80 10, 2008. The person(s) controlling the copyright in some of this 81 material may not have granted the IETF Trust the right to allow 82 modifications of such material outside the IETF Standards Process. 83 Without obtaining an adequate license from the person(s) controlling 84 the copyright in such materials, this document may not be modified 85 outside the IETF Standards Process, and derivative works of it may 86 not be created outside the IETF Standards Process, except to format 87 it for publication as an RFC or to translate it into languages other 88 than English. 90 Table of Contents 92 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 93 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 94 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 95 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6 96 1.2.2. ABNF Rules defined in other Parts of the 97 Specification . . . . . . . . . . . . . . . . . . . . 6 98 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 6 99 2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 6 100 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7 101 3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 7 102 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 8 103 4. Combining Ranges . . . . . . . . . . . . . . . . . . . . . . . 8 104 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 8 105 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 9 106 5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 9 107 5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 11 108 5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 12 109 5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 12 110 5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 14 111 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 112 6.1. Status Code Registration . . . . . . . . . . . . . . . . . 15 113 6.2. Header Field Registration . . . . . . . . . . . . . . . . 15 114 6.3. Range Specifier Registration . . . . . . . . . . . . . . . 16 115 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 116 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 117 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 118 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 119 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 120 Appendix A. Internet Media Type multipart/byteranges . . . . . . 17 121 Appendix B. Compatibility with Previous Versions . . . . . . . . 20 122 B.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 20 123 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 20 124 Appendix D. Change Log (to be removed by RFC Editor before 125 publication) . . . . . . . . . . . . . . . . . . . . 21 126 D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 21 127 D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 21 128 D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 22 129 D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 22 130 D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 22 131 D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 22 132 D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 22 133 D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 23 134 D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 23 135 D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 23 136 D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 23 137 D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 23 139 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 141 1. Introduction 143 HTTP clients often encounter interrupted data transfers as a result 144 of cancelled requests or dropped connections. When a cache has 145 stored a partial representation, it is desirable to request the 146 remainder of that representation in a subsequent request rather than 147 transfer the entire representation. There are also a number of Web 148 applications that benefit from being able to request only a subset of 149 a larger representation, such as a single page of a very large 150 document or only part of an image to be rendered by a device with 151 limited local storage. 153 This document defines HTTP/1.1 range requests, partial responses, and 154 the multipart/byteranges media type. The protocol for range requests 155 is an OPTIONAL feature of HTTP, designed so resources or recipients 156 that do not implement this feature can respond as if it is a normal 157 GET request without impacting interoperability. Partial responses 158 are indicated by a distinct status code to not be mistaken for full 159 responses by intermediate caches that might not implement the 160 feature. 162 Although the HTTP range request mechanism is designed to allow for 163 extensible range types, this specification only defines requests for 164 byte ranges. 166 1.1. Requirements 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in [RFC2119]. 172 An implementation is not compliant if it fails to satisfy one or more 173 of the "MUST" or "REQUIRED" level requirements for the protocols it 174 implements. An implementation that satisfies all the "MUST" or 175 "REQUIRED" level and all the "SHOULD" level requirements for its 176 protocols is said to be "unconditionally compliant"; one that 177 satisfies all the "MUST" level requirements but not all the "SHOULD" 178 level requirements for its protocols is said to be "conditionally 179 compliant". 181 1.2. Syntax Notation 183 This specification uses the ABNF syntax defined in Section 1.2 of 184 [Part1] (which extends the syntax defined in [RFC5234] with a list 185 rule). Appendix C shows the collected ABNF, with the list rule 186 expanded. 188 The following core rules are included by reference, as defined in 190 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 191 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 192 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit 193 sequence of data), SP (space), VCHAR (any visible USASCII character), 194 and WSP (whitespace). 196 1.2.1. Core Rules 198 The core rules below are defined in Section 1.2.2 of [Part1]: 200 token = 201 OWS = 203 1.2.2. ABNF Rules defined in other Parts of the Specification 205 The ABNF rules below are defined in other parts: 207 HTTP-date = 209 entity-tag = 211 2. Range Units 213 HTTP/1.1 allows a client to request that only part (a range of) the 214 representation be included within the response. HTTP/1.1 uses range 215 units in the Range (Section 5.4) and Content-Range (Section 5.2) 216 header fields. A representation can be broken down into subranges 217 according to various structural units. 219 range-unit = bytes-unit / other-range-unit 220 bytes-unit = "bytes" 221 other-range-unit = token 223 HTTP/1.1 has been designed to allow implementations of applications 224 that do not depend on knowledge of ranges. The only range unit 225 defined by HTTP/1.1 is "bytes". Additional specifiers can be defined 226 as described in Section 2.1. 228 If a range unit is not understood in a request, a server MUST ignore 229 the whole Range header (Section 5.4). If a range unit is not 230 understood in a response, an intermediary SHOULD pass the response to 231 the client; a client MUST fail. 233 2.1. Range Specifier Registry 235 The HTTP Ranger Specifier Registry defines the name space for the 236 range specifier names. 238 Registrations MUST include the following fields: 240 o Name 242 o Description 244 o Pointer to specification text 246 Values to be added to this name space are subject to IETF review 247 ([RFC5226], Section 4.1). 249 The registry itself is maintained at 250 . 252 3. Status Code Definitions 254 3.1. 206 Partial Content 256 The server has fulfilled the partial GET request for the resource. 257 The request MUST have included a Range header field (Section 5.4) 258 indicating the desired range, and MAY have included an If-Range 259 header field (Section 5.3) to make the request conditional. 261 The response MUST include the following header fields: 263 o Either a Content-Range header field (Section 5.2) indicating the 264 range included with this response, or a multipart/byteranges 265 Content-Type including Content-Range fields for each part. If a 266 Content-Length header field is present in the response, its value 267 MUST match the actual number of octets transmitted in the message- 268 body. 270 o Date 272 o Cache-Control, ETag, Expires, Content-Location, Last-Modified, 273 and/or Vary, if the header field would have been sent in a 200 274 response to the same request 276 If the 206 response is the result of an If-Range request, the 277 response SHOULD NOT include other representation header fields. 278 Otherwise, the response MUST include all of the representation header 279 fields that would have been returned with a 200 (OK) response to the 280 same request. 282 A cache MUST NOT combine a 206 response with other previously cached 283 content if the ETag or Last-Modified headers do not match exactly, 284 see Section 4. 286 A cache that does not support the Range and Content-Range headers 287 MUST NOT cache 206 (Partial Content) responses. Furthermore, if a 288 response uses a range unit that is not understood by the cache, then 289 it MUST NOT be cached either. 291 3.2. 416 Requested Range Not Satisfiable 293 A server SHOULD return a response with this status code if a request 294 included a Range request-header field (Section 5.4), and none of the 295 ranges-specifier values in this field overlap the current extent of 296 the selected resource, and the request did not include an If-Range 297 request-header field (Section 5.3). (For byte-ranges, this means 298 that the first-byte-pos of all of the byte-range-spec values were 299 greater than the current length of the selected resource.) 301 When this status code is returned for a byte-range request, the 302 response SHOULD include a Content-Range header field specifying the 303 current length of the representation (see Section 5.2). This 304 response MUST NOT use the multipart/byteranges content-type. 306 4. Combining Ranges 308 A response might transfer only a subrange of a representation, either 309 because the request included one or more Range specifications, or 310 because a connection closed prematurely. After several such 311 transfers, a cache might have received several ranges of the same 312 representation. 314 If a cache has a stored non-empty set of subranges for a 315 representation, and an incoming response transfers another subrange, 316 the cache MAY combine the new subrange with the existing set if both 317 the following conditions are met: 319 o Both the incoming response and the cache entry have a cache 320 validator. 322 o The two cache validators match using the strong comparison 323 function (see Section 4 of [Part4]). 325 If either requirement is not met, the cache MUST use only the most 326 recent partial response (based on the Date values transmitted with 327 every response, and using the incoming response if these values are 328 equal or missing), and MUST discard the other partial information. 330 5. Header Field Definitions 332 This section defines the syntax and semantics of HTTP/1.1 header 333 fields related to range requests and partial responses. 335 5.1. Accept-Ranges 337 The "Accept-Ranges" response-header field allows a resource to 338 indicate its acceptance of range requests. 340 Accept-Ranges = "Accept-Ranges" ":" OWS Accept-Ranges-v 341 Accept-Ranges-v = acceptable-ranges 342 acceptable-ranges = 1#range-unit / "none" 344 Origin servers that accept byte-range requests MAY send 346 Accept-Ranges: bytes 348 but are not required to do so. Clients MAY generate range requests 349 without having received this header for the resource involved. Range 350 units are defined in Section 2. 352 Servers that do not accept any kind of range request for a resource 353 MAY send 355 Accept-Ranges: none 357 to advise the client not to attempt a range request. 359 5.2. Content-Range 361 The "Content-Range" header field is sent with a partial 362 representation to specify where in the full representation the 363 payload body is intended to be applied. 365 Range units are defined in Section 2. 367 Content-Range = "Content-Range" ":" OWS Content-Range-v 368 Content-Range-v = content-range-spec 370 content-range-spec = byte-content-range-spec 371 / other-content-range-spec 372 byte-content-range-spec = bytes-unit SP 373 byte-range-resp-spec "/" 374 ( instance-length / "*" ) 376 byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) 377 / "*" 379 instance-length = 1*DIGIT 381 other-content-range-spec = other-range-unit SP 382 other-range-resp-spec 384 other-range-resp-spec = *CHAR 386 The header SHOULD indicate the total length of the full 387 representation, unless this length is unknown or difficult to 388 determine. The asterisk "*" character means that the instance-length 389 is unknown at the time when the response was generated. 391 Unlike byte-ranges-specifier values (see Section 5.4.1), a byte- 392 range-resp-spec MUST only specify one range, and MUST contain 393 absolute byte positions for both the first and last byte of the 394 range. 396 A byte-content-range-spec with a byte-range-resp-spec whose last- 397 byte-pos value is less than its first-byte-pos value, or whose 398 instance-length value is less than or equal to its last-byte-pos 399 value, is invalid. The recipient of an invalid byte-content-range- 400 spec MUST ignore it and any content transferred along with it. 402 In the case of a byte range request: A server sending a response with 403 status code 416 (Requested range not satisfiable) SHOULD include a 404 Content-Range field with a byte-range-resp-spec of "*". The 405 instance-length specifies the current length of the selected 406 resource. A response with status code 206 (Partial Content) MUST NOT 407 include a Content-Range field with a byte-range-resp-spec of "*". 409 Examples of byte-content-range-spec values, assuming that the 410 representation contains a total of 1234 bytes: 412 o The first 500 bytes: 414 bytes 0-499/1234 416 o The second 500 bytes: 418 bytes 500-999/1234 420 o All except for the first 500 bytes: 422 bytes 500-1233/1234 424 o The last 500 bytes: 426 bytes 734-1233/1234 428 When an HTTP message includes the content of a single range (for 429 example, a response to a request for a single range, or to a request 430 for a set of ranges that overlap without any holes), this content is 431 transmitted with a Content-Range header, and a Content-Length header 432 showing the number of bytes actually transferred. For example, 434 HTTP/1.1 206 Partial Content 435 Date: Wed, 15 Nov 1995 06:25:24 GMT 436 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 437 Content-Range: bytes 21010-47021/47022 438 Content-Length: 26012 439 Content-Type: image/gif 441 When an HTTP message includes the content of multiple ranges (for 442 example, a response to a request for multiple non-overlapping 443 ranges), these are transmitted as a multipart message. The multipart 444 media type used for this purpose is "multipart/byteranges" as defined 445 in Appendix A. 447 A response to a request for a single range MUST NOT be sent using the 448 multipart/byteranges media type. A response to a request for 449 multiple ranges, whose result is a single range, MAY be sent as a 450 multipart/byteranges media type with one part. A client that cannot 451 decode a multipart/byteranges message MUST NOT ask for multiple 452 ranges in a single request. 454 When a client requests multiple ranges in one request, the server 455 SHOULD return them in the order that they appeared in the request. 457 If the server ignores a byte-range-spec because it is syntactically 458 invalid, the server SHOULD treat the request as if the invalid Range 459 header field did not exist. (Normally, this means return a 200 460 response containing the full representation). 462 If the server receives a request (other than one including an If- 463 Range request-header field) with an unsatisfiable Range request- 464 header field (that is, all of whose byte-range-spec values have a 465 first-byte-pos value greater than the current length of the selected 466 resource), it SHOULD return a response code of 416 (Requested range 467 not satisfiable) (Section 3.2). 469 Note: Clients cannot depend on servers to send a 416 (Requested 470 range not satisfiable) response instead of a 200 (OK) response for 471 an unsatisfiable Range request-header, since not all servers 472 implement this request-header. 474 5.3. If-Range 476 If a client has a partial copy of a representation in its cache, and 477 wishes to have an up-to-date copy of the entire representation in its 478 cache, it could use the Range request-header with a conditional GET 479 (using either or both of If-Unmodified-Since and If-Match.) However, 480 if the condition fails because the representation has been modified, 481 the client would then have to make a second request to obtain the 482 entire current representation. 484 The "If-Range" request-header field allows a client to "short- 485 circuit" the second request. Informally, its meaning is "if the 486 representation is unchanged, send me the part(s) that I am missing; 487 otherwise, send me the entire new representation". 489 If-Range = "If-Range" ":" OWS If-Range-v 490 If-Range-v = entity-tag / HTTP-date 492 If the client has no entity-tag for a representation, but does have a 493 Last-Modified date, it MAY use that date in an If-Range header. (The 494 server can distinguish between a valid HTTP-date and any form of 495 entity-tag by examining no more than two characters.) The If-Range 496 header SHOULD only be used together with a Range header, and MUST be 497 ignored if the request does not include a Range header, or if the 498 server does not support the sub-range operation. 500 If the entity-tag given in the If-Range header matches the current 501 cache validator for the representation, then the server SHOULD 502 provide the specified sub-range of the representation using a 206 503 (Partial Content) response. If the cache validator does not match, 504 then the server SHOULD return the entire representation using a 200 505 (OK) response. 507 5.4. Range 509 5.4.1. Byte Ranges 511 Since all HTTP representations are transferred as sequences of bytes, 512 the concept of a byte range is meaningful for any HTTP 513 representation. (However, not all clients and servers need to 514 support byte-range operations.) 516 Byte range specifications in HTTP apply to the sequence of bytes in 517 the representation body (not necessarily the same as the message- 518 body). 520 A byte range operation MAY specify a single range of bytes, or a set 521 of ranges within a single representation. 523 byte-ranges-specifier = bytes-unit "=" byte-range-set 524 byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec ) 525 byte-range-spec = first-byte-pos "-" [ last-byte-pos ] 526 first-byte-pos = 1*DIGIT 527 last-byte-pos = 1*DIGIT 529 The first-byte-pos value in a byte-range-spec gives the byte-offset 530 of the first byte in a range. The last-byte-pos value gives the 531 byte-offset of the last byte in the range; that is, the byte 532 positions specified are inclusive. Byte offsets start at zero. 534 If the last-byte-pos value is present, it MUST be greater than or 535 equal to the first-byte-pos in that byte-range-spec, or the byte- 536 range-spec is syntactically invalid. The recipient of a byte-range- 537 set that includes one or more syntactically invalid byte-range-spec 538 values MUST ignore the header field that includes that byte-range- 539 set. 541 If the last-byte-pos value is absent, or if the value is greater than 542 or equal to the current length of the representation body, last-byte- 543 pos is taken to be equal to one less than the current length of the 544 representation in bytes. 546 By its choice of last-byte-pos, a client can limit the number of 547 bytes retrieved without knowing the size of the representation. 549 suffix-byte-range-spec = "-" suffix-length 550 suffix-length = 1*DIGIT 552 A suffix-byte-range-spec is used to specify the suffix of the 553 representation body, of a length given by the suffix-length value. 554 (That is, this form specifies the last N bytes of a representation.) 555 If the representation is shorter than the specified suffix-length, 556 the entire representation is used. 558 If a syntactically valid byte-range-set includes at least one byte- 559 range-spec whose first-byte-pos is less than the current length of 560 the representation, or at least one suffix-byte-range-spec with a 561 non-zero suffix-length, then the byte-range-set is satisfiable. 562 Otherwise, the byte-range-set is unsatisfiable. If the byte-range- 563 set is unsatisfiable, the server SHOULD return a response with a 416 564 (Requested range not satisfiable) status code. Otherwise, the server 565 SHOULD return a response with a 206 (Partial Content) status code 566 containing the satisfiable ranges of the representation. 568 Examples of byte-ranges-specifier values (assuming a representation 569 of length 10000): 571 o The first 500 bytes (byte offsets 0-499, inclusive): 573 bytes=0-499 575 o The second 500 bytes (byte offsets 500-999, inclusive): 577 bytes=500-999 579 o The final 500 bytes (byte offsets 9500-9999, inclusive): 581 bytes=-500 583 Or: 585 bytes=9500- 587 o The first and last bytes only (bytes 0 and 9999): 589 bytes=0-0,-1 591 o Several legal but not canonical specifications of the second 500 592 bytes (byte offsets 500-999, inclusive): 594 bytes=500-600,601-999 595 bytes=500-700,601-999 597 5.4.2. Range Retrieval Requests 599 The "Range" request-header field defines the GET method (conditional 600 or not) to request one or more sub-ranges of the response 601 representation body, instead of the entire representation body. 603 Range = "Range" ":" OWS Range-v 604 Range-v = byte-ranges-specifier 605 / other-ranges-specifier 606 other-ranges-specifier = other-range-unit "=" other-range-set 607 other-range-set = 1*CHAR 609 A server MAY ignore the Range header. However, HTTP/1.1 origin 610 servers and intermediate caches ought to support byte ranges when 611 possible, since Range supports efficient recovery from partially 612 failed transfers, and supports efficient partial retrieval of large 613 representations. 615 If the server supports the Range header and the specified range or 616 ranges are appropriate for the representation: 618 o The presence of a Range header in an unconditional GET modifies 619 what is returned if the GET is otherwise successful. In other 620 words, the response carries a status code of 206 (Partial Content) 621 instead of 200 (OK). 623 o The presence of a Range header in a conditional GET (a request 624 using one or both of If-Modified-Since and If-None-Match, or one 625 or both of If-Unmodified-Since and If-Match) modifies what is 626 returned if the GET is otherwise successful and the condition is 627 true. It does not affect the 304 (Not Modified) response returned 628 if the conditional is false. 630 In some cases, it might be more appropriate to use the If-Range 631 header (see Section 5.3) in addition to the Range header. 633 If a proxy that supports ranges receives a Range request, forwards 634 the request to an inbound server, and receives an entire 635 representation in reply, it SHOULD only return the requested range to 636 its client. It SHOULD store the entire received response in its 637 cache if that is consistent with its cache allocation policies. 639 6. IANA Considerations 641 6.1. Status Code Registration 643 The HTTP Status Code Registry located at 644 shall be updated 645 with the registrations below: 647 +-------+---------------------------------+-------------+ 648 | Value | Description | Reference | 649 +-------+---------------------------------+-------------+ 650 | 206 | Partial Content | Section 3.1 | 651 | 416 | Requested Range Not Satisfiable | Section 3.2 | 652 +-------+---------------------------------+-------------+ 654 6.2. Header Field Registration 656 The Message Header Field Registry located at shall be 658 updated with the permanent registrations below (see [RFC3864]): 660 +-------------------+----------+----------+-------------+ 661 | Header Field Name | Protocol | Status | Reference | 662 +-------------------+----------+----------+-------------+ 663 | Accept-Ranges | http | standard | Section 5.1 | 664 | Content-Range | http | standard | Section 5.2 | 665 | If-Range | http | standard | Section 5.3 | 666 | Range | http | standard | Section 5.4 | 667 +-------------------+----------+----------+-------------+ 669 The change controller is: "IETF (iesg@ietf.org) - Internet 670 Engineering Task Force". 672 6.3. Range Specifier Registration 674 The registration procedure for HTTP Range Specifiers is defined by 675 Section 2.1 of this document. 677 The HTTP Range Specifier Registry shall be created at 678 and be 679 populated with the registrations below: 681 +----------------------+-------------------+----------------------+ 682 | Range Specifier Name | Description | Reference | 683 +----------------------+-------------------+----------------------+ 684 | bytes | a range of octets | (this specification) | 685 +----------------------+-------------------+----------------------+ 687 The change controller is: "IETF (iesg@ietf.org) - Internet 688 Engineering Task Force". 690 7. Security Considerations 692 No additional security considerations have been identified beyond 693 those applicable to HTTP in general [Part1]. 695 8. Acknowledgments 697 Most of the specification of ranges is based on work originally done 698 by Ari Luotonen and John Franks, with additional input from Steve 699 Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin 700 Hamilton, Koen Holtman, Shel Kaplan, Paul Leach, Alex Lopez-Ortiz, 701 Larry Masinter, Jeff Mogul, Lou Montulli, David W. Morris, Luigi 702 Rizzo, and Bill Weihl. 704 9. References 706 9.1. Normative References 708 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 709 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 710 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, 711 and Message Parsing", draft-ietf-httpbis-p1-messaging-11 712 (work in progress), August 2010. 714 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 715 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 716 and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional 717 Requests", draft-ietf-httpbis-p4-conditional-11 (work in 718 progress), August 2010. 720 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 721 Extensions (MIME) Part Two: Media Types", RFC 2046, 722 November 1996. 724 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 725 Requirement Levels", BCP 14, RFC 2119, March 1997. 727 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 728 Specifications: ABNF", STD 68, RFC 5234, January 2008. 730 9.2. Informative References 732 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 733 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 734 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 736 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 737 Procedures for Message Header Fields", BCP 90, RFC 3864, 738 September 2004. 740 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 741 Registration Procedures", BCP 13, RFC 4288, December 2005. 743 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 744 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 745 May 2008. 747 Appendix A. Internet Media Type multipart/byteranges 749 When an HTTP 206 (Partial Content) response message includes the 750 content of multiple ranges (a response to a request for multiple non- 751 overlapping ranges), these are transmitted as a multipart message- 752 body ([RFC2046], Section 5.1). The media type for this purpose is 753 called "multipart/byteranges". The following is to be registered 754 with IANA [RFC4288]. 756 Note: Despite the name "multipart/byteranges" is not limited to 757 the byte ranges only. 759 The multipart/byteranges media type includes one or more parts, each 760 with its own Content-Type and Content-Range fields. The required 761 boundary parameter specifies the boundary string used to separate 762 each body-part. 764 Type name: multipart 766 Subtype name: byteranges 768 Required parameters: boundary 770 Optional parameters: none 772 Encoding considerations: only "7bit", "8bit", or "binary" are 773 permitted 775 Security considerations: none 777 Interoperability considerations: none 779 Published specification: This specification (see Appendix A). 781 Applications that use this media type: 783 Additional information: 785 Magic number(s): none 787 File extension(s): none 789 Macintosh file type code(s): none 791 Person and email address to contact for further information: See 792 Authors Section. 794 Intended usage: COMMON 796 Restrictions on usage: none 798 Author/Change controller: IESG 799 For example: 801 HTTP/1.1 206 Partial Content 802 Date: Wed, 15 Nov 1995 06:25:24 GMT 803 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 804 Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES 806 --THIS_STRING_SEPARATES 807 Content-type: application/pdf 808 Content-range: bytes 500-999/8000 810 ...the first range... 811 --THIS_STRING_SEPARATES 812 Content-type: application/pdf 813 Content-range: bytes 7000-7999/8000 815 ...the second range 816 --THIS_STRING_SEPARATES-- 818 Other example: 820 HTTP/1.1 206 Partial Content 821 Date: Tue, 14 Nov 1995 06:25:24 GMT 822 Last-Modified: Tue, 14 July 04:58:08 GMT 823 Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES 825 --THIS_STRING_SEPARATES 826 Content-type: video/example 827 Content-range: exampleunit 1.2-4.3/25 829 ...the first range... 830 --THIS_STRING_SEPARATES 831 Content-type: video/example 832 Content-range: exampleunit 11.2-14.3/25 834 ...the second range 835 --THIS_STRING_SEPARATES-- 837 Notes: 839 1. Additional CRLFs MAY precede the first boundary string in the 840 body. 842 2. Although [RFC2046] permits the boundary string to be quoted, some 843 existing implementations handle a quoted boundary string 844 incorrectly. 846 3. A number of browsers and servers were coded to an early draft of 847 the byteranges specification to use a media type of multipart/ 848 x-byteranges, which is almost, but not quite compatible with the 849 version documented in HTTP/1.1. 851 Appendix B. Compatibility with Previous Versions 853 B.1. Changes from RFC 2616 855 Clarify that it is not ok to use a weak cache validator in a 206 856 response. (Section 3.1) 858 Clarify that multipart/byteranges can consist of a single part. 859 (Appendix A) 861 Appendix C. Collected ABNF 863 Accept-Ranges = "Accept-Ranges:" OWS Accept-Ranges-v 864 Accept-Ranges-v = acceptable-ranges 866 Content-Range = "Content-Range:" OWS Content-Range-v 867 Content-Range-v = content-range-spec 869 HTTP-date = 871 If-Range = "If-Range:" OWS If-Range-v 872 If-Range-v = entity-tag / HTTP-date 874 OWS = 876 Range = "Range:" OWS Range-v 877 Range-v = byte-ranges-specifier / other-ranges-specifier 879 acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS 880 range-unit ] ) ) / "none" 882 byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" ( 883 instance-length / "*" ) 884 byte-range-resp-spec = ( first-byte-pos "-" last-byte-pos ) / "*" 885 byte-range-set = ( *( "," OWS ) byte-range-spec ) / ( 886 suffix-byte-range-spec *( OWS "," [ ( OWS byte-range-spec ) / 887 suffix-byte-range-spec ] ) ) 888 byte-range-spec = first-byte-pos "-" [ last-byte-pos ] 889 byte-ranges-specifier = bytes-unit "=" byte-range-set 890 bytes-unit = "bytes" 892 content-range-spec = byte-content-range-spec / 893 other-content-range-spec 895 entity-tag = 897 first-byte-pos = 1*DIGIT 899 instance-length = 1*DIGIT 901 last-byte-pos = 1*DIGIT 903 other-content-range-spec = other-range-unit SP other-range-resp-spec 904 other-range-resp-spec = *CHAR 905 other-range-set = 1*CHAR 906 other-range-unit = token 907 other-ranges-specifier = other-range-unit "=" other-range-set 909 range-unit = bytes-unit / other-range-unit 911 suffix-byte-range-spec = "-" suffix-length 912 suffix-length = 1*DIGIT 914 token = 916 ABNF diagnostics: 918 ; Accept-Ranges defined but not used 919 ; Content-Range defined but not used 920 ; If-Range defined but not used 921 ; Range defined but not used 923 Appendix D. Change Log (to be removed by RFC Editor before publication) 925 D.1. Since RFC2616 927 Extracted relevant partitions from [RFC2616]. 929 D.2. Since draft-ietf-httpbis-p5-range-00 931 Closed issues: 933 o : "Cache 934 validators in 206 responses" 935 () 937 o : "Normative and 938 Informative references" 940 o : "Normative up- 941 to-date references" 943 D.3. Since draft-ietf-httpbis-p5-range-01 945 Closed issues: 947 o : "Updating to 948 RFC4288" 950 Ongoing work on ABNF conversion 951 (): 953 o Add explicit references to BNF syntax and rules imported from 954 other parts of the specification. 956 D.4. Since draft-ietf-httpbis-p5-range-02 958 Ongoing work on IANA Message Header Registration 959 (): 961 o Reference RFC 3984, and update header registrations for headers 962 defined in this document. 964 D.5. Since draft-ietf-httpbis-p5-range-03 966 D.6. Since draft-ietf-httpbis-p5-range-04 968 Closed issues: 970 o : "multipart/ 971 byteranges minimum number of parts" 973 Ongoing work on ABNF conversion 974 (): 976 o Use "/" instead of "|" for alternatives. 978 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 979 whitespace ("OWS") and required whitespace ("RWS"). 981 o Rewrite ABNFs to spell out whitespace rules, factor out header 982 value format definitions. 984 D.7. Since draft-ietf-httpbis-p5-range-05 986 Closed issues: 988 o : "State base 989 for *-byte-pos and suffix-length" 991 Ongoing work on Custom Ranges 992 (): 994 o Remove bias in favor of byte ranges; allow custom ranges in ABNF. 996 Final work on ABNF conversion 997 (): 999 o Add appendix containing collected and expanded ABNF, reorganize 1000 ABNF introduction. 1002 D.8. Since draft-ietf-httpbis-p5-range-06 1004 Closed issues: 1006 o : "base for 1007 numeric protocol elements" 1009 D.9. Since draft-ietf-httpbis-p5-range-07 1011 Closed issues: 1013 o Fixed discrepancy in the If-Range definition about allowed 1014 validators. 1016 o : "multipart/ 1017 byteranges for custom range units" 1019 o : "range unit 1020 missing from other-ranges-specifier in Range header" 1022 o : "move IANA 1023 registrations for optional status codes" 1025 D.10. Since draft-ietf-httpbis-p5-range-08 1027 No significant changes. 1029 D.11. Since draft-ietf-httpbis-p5-range-09 1031 No significant changes. 1033 D.12. Since draft-ietf-httpbis-p5-range-10 1035 Closed issues: 1037 o : "Clarify 1038 'Requested Variant'" 1040 o : "Clarify 1041 entity / representation / variant terminology" 1043 o : "consider 1044 removing the 'changes from 2068' sections" 1046 Ongoing work on Custom Ranges 1047 (): 1049 o Add IANA registry. 1051 Index 1053 2 1054 206 Partial Content (status code) 7 1056 4 1057 416 Requested Range Not Satisfiable (status code) 8 1059 A 1060 Accept-Ranges header 9 1062 C 1063 Content-Range header 9 1065 G 1066 Grammar 1067 Accept-Ranges 9 1068 Accept-Ranges-v 9 1069 acceptable-ranges 9 1070 byte-content-range-spec 9 1071 byte-range-resp-spec 9 1072 byte-range-set 12 1073 byte-range-spec 12 1074 byte-ranges-specifier 12 1075 bytes-unit 6 1076 Content-Range 9 1077 content-range-spec 9 1078 Content-Range-v 9 1079 first-byte-pos 12 1080 If-Range 12 1081 If-Range-v 12 1082 instance-length 9 1083 last-byte-pos 12 1084 other-range-unit 6 1085 Range 14 1086 range-unit 6 1087 ranges-specifier 12 1088 suffix-byte-range-spec 13 1089 suffix-length 13 1091 H 1092 Headers 1093 Accept-Ranges 9 1094 Content-Range 9 1095 If-Range 11 1096 Range 12 1098 I 1099 If-Range header 11 1101 M 1102 Media Type 1103 multipart/byteranges 17 1104 multipart/x-byteranges 20 1105 multipart/byteranges Media Type 17 1106 multipart/x-byteranges Media Type 20 1108 R 1109 Range header 12 1111 S 1112 Status Codes 1113 206 Partial Content 7 1114 416 Requested Range Not Satisfiable 8 1116 Authors' Addresses 1118 Roy T. Fielding (editor) 1119 Day Software 1120 23 Corporate Plaza DR, Suite 280 1121 Newport Beach, CA 92660 1122 USA 1124 Phone: +1-949-706-5300 1125 Fax: +1-949-706-5305 1126 EMail: fielding@gbiv.com 1127 URI: http://roy.gbiv.com/ 1128 Jim Gettys 1129 Alcatel-Lucent Bell Labs 1130 21 Oak Knoll Road 1131 Carlisle, MA 01741 1132 USA 1134 EMail: jg@freedesktop.org 1135 URI: http://gettys.wordpress.com/ 1137 Jeffrey C. Mogul 1138 Hewlett-Packard Company 1139 HP Labs, Large Scale Systems Group 1140 1501 Page Mill Road, MS 1177 1141 Palo Alto, CA 94304 1142 USA 1144 EMail: JeffMogul@acm.org 1146 Henrik Frystyk Nielsen 1147 Microsoft Corporation 1148 1 Microsoft Way 1149 Redmond, WA 98052 1150 USA 1152 EMail: henrikn@microsoft.com 1154 Larry Masinter 1155 Adobe Systems, Incorporated 1156 345 Park Ave 1157 San Jose, CA 95110 1158 USA 1160 EMail: LMM@acm.org 1161 URI: http://larry.masinter.net/ 1163 Paul J. Leach 1164 Microsoft Corporation 1165 1 Microsoft Way 1166 Redmond, WA 98052 1168 EMail: paulle@microsoft.com 1169 Tim Berners-Lee 1170 World Wide Web Consortium 1171 MIT Computer Science and Artificial Intelligence Laboratory 1172 The Stata Center, Building 32 1173 32 Vassar Street 1174 Cambridge, MA 02139 1175 USA 1177 EMail: timbl@w3.org 1178 URI: http://www.w3.org/People/Berners-Lee/ 1180 Yves Lafon (editor) 1181 World Wide Web Consortium 1182 W3C / ERCIM 1183 2004, rte des Lucioles 1184 Sophia-Antipolis, AM 06902 1185 France 1187 EMail: ylafon@w3.org 1188 URI: http://www.raubacapeu.net/people/yves/ 1190 Julian F. Reschke (editor) 1191 greenbytes GmbH 1192 Hafenweg 16 1193 Muenster, NW 48155 1194 Germany 1196 Phone: +49 251 2807760 1197 Fax: +49 251 2807761 1198 EMail: julian.reschke@greenbytes.de 1199 URI: http://greenbytes.de/tech/webdav/