idnits 2.17.1 draft-ietf-httpbis-p5-range-12.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 (October 25, 2010) is 4931 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-12 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-12 -- 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: April 28, 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 October 25, 2010 22 HTTP/1.1, part 5: Range Requests and Partial Responses 23 draft-ietf-httpbis-p5-range-12 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.13. 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 April 28, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 93 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 94 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 95 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5 96 1.2.2. ABNF Rules defined in other Parts of the 97 Specification . . . . . . . . . . . . . . . . . . . . 5 98 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 5 99 2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 5 100 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 6 101 3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 6 102 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 7 103 4. Combining Ranges . . . . . . . . . . . . . . . . . . . . . . . 7 104 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 7 105 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 8 106 5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 8 107 5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 10 108 5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 11 109 5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 11 110 5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 13 111 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 112 6.1. Status Code Registration . . . . . . . . . . . . . . . . . 14 113 6.2. Header Field Registration . . . . . . . . . . . . . . . . 14 114 6.3. Range Specifier Registration . . . . . . . . . . . . . . . 15 115 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 116 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 117 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 118 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 119 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 120 Appendix A. Internet Media Type multipart/byteranges . . . . . . 16 121 Appendix B. Compatibility with Previous Versions . . . . . . . . 19 122 B.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 19 123 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 19 124 Appendix D. Change Log (to be removed by RFC Editor before 125 publication) . . . . . . . . . . . . . . . . . . . . 20 126 D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 20 127 D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 20 128 D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 21 129 D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 21 130 D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 21 131 D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 21 132 D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 21 133 D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 22 134 D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 22 135 D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 22 136 D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 22 137 D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 22 138 D.13. Since draft-ietf-httpbis-p5-range-11 . . . . . . . . . . . 23 139 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 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 field (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 header fields do not match 284 exactly, see Section 4. 286 A cache that does not support the Range and Content-Range header 287 fields MUST NOT cache 206 (Partial Content) responses. Furthermore, 288 if a response uses a range unit that is not understood by the cache, 289 then 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 field for the resource involved. 350 Range 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 field 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 field, and a Content-Length 432 header field showing the number of bytes actually transferred. For 433 example, 435 HTTP/1.1 206 Partial Content 436 Date: Wed, 15 Nov 1995 06:25:24 GMT 437 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 438 Content-Range: bytes 21010-47021/47022 439 Content-Length: 26012 440 Content-Type: image/gif 442 When an HTTP message includes the content of multiple ranges (for 443 example, a response to a request for multiple non-overlapping 444 ranges), these are transmitted as a multipart message. The multipart 445 media type used for this purpose is "multipart/byteranges" as defined 446 in Appendix A. 448 A response to a request for a single range MUST NOT be sent using the 449 multipart/byteranges media type. A response to a request for 450 multiple ranges, whose result is a single range, MAY be sent as a 451 multipart/byteranges media type with one part. A client that cannot 452 decode a multipart/byteranges message MUST NOT ask for multiple 453 ranges in a single request. 455 When a client requests multiple ranges in one request, the server 456 SHOULD return them in the order that they appeared in the request. 458 If the server ignores a byte-range-spec because it is syntactically 459 invalid, the server SHOULD treat the request as if the invalid Range 460 header field did not exist. (Normally, this means return a 200 461 response containing the full representation). 463 If the server receives a request (other than one including an If- 464 Range request-header field) with an unsatisfiable Range request- 465 header field (that is, all of whose byte-range-spec values have a 466 first-byte-pos value greater than the current length of the selected 467 resource), it SHOULD return a response code of 416 (Requested range 468 not satisfiable) (Section 3.2). 470 Note: Clients cannot depend on servers to send a 416 (Requested 471 range not satisfiable) response instead of a 200 (OK) response for 472 an unsatisfiable Range request-header field, since not all servers 473 implement this request-header field. 475 5.3. If-Range 477 If a client has a partial copy of a representation in its cache, and 478 wishes to have an up-to-date copy of the entire representation in its 479 cache, it could use the Range request-header field with a conditional 480 GET (using either or both of If-Unmodified-Since and If-Match.) 481 However, if the condition fails because the representation has been 482 modified, the client would then have to make a second request to 483 obtain the entire current representation. 485 The "If-Range" request-header field allows a client to "short- 486 circuit" the second request. Informally, its meaning is "if the 487 representation is unchanged, send me the part(s) that I am missing; 488 otherwise, send me the entire new representation". 490 If-Range = "If-Range" ":" OWS If-Range-v 491 If-Range-v = entity-tag / HTTP-date 493 If the client has no entity-tag for a representation, but does have a 494 Last-Modified date, it MAY use that date in an If-Range header field. 495 (The server can distinguish between a valid HTTP-date and any form of 496 entity-tag by examining no more than two characters.) The If-Range 497 header field SHOULD only be used together with a Range header field, 498 and MUST be ignored if the request does not include a Range header 499 field, or if the server does not support the sub-range operation. 501 If the entity-tag given in the If-Range header field matches the 502 current cache validator for the representation, then the server 503 SHOULD provide the specified sub-range of the representation using a 504 206 (Partial Content) response. If the cache validator does not 505 match, then the server SHOULD return the entire representation using 506 a 200 (OK) response. 508 5.4. Range 510 5.4.1. Byte Ranges 512 Since all HTTP representations are transferred as sequences of bytes, 513 the concept of a byte range is meaningful for any HTTP 514 representation. (However, not all clients and servers need to 515 support byte-range operations.) 517 Byte range specifications in HTTP apply to the sequence of bytes in 518 the representation body (not necessarily the same as the message- 519 body). 521 A byte range operation MAY specify a single range of bytes, or a set 522 of ranges within a single representation. 524 byte-ranges-specifier = bytes-unit "=" byte-range-set 525 byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec ) 526 byte-range-spec = first-byte-pos "-" [ last-byte-pos ] 527 first-byte-pos = 1*DIGIT 528 last-byte-pos = 1*DIGIT 530 The first-byte-pos value in a byte-range-spec gives the byte-offset 531 of the first byte in a range. The last-byte-pos value gives the 532 byte-offset of the last byte in the range; that is, the byte 533 positions specified are inclusive. Byte offsets start at zero. 535 If the last-byte-pos value is present, it MUST be greater than or 536 equal to the first-byte-pos in that byte-range-spec, or the byte- 537 range-spec is syntactically invalid. The recipient of a byte-range- 538 set that includes one or more syntactically invalid byte-range-spec 539 values MUST ignore the header field that includes that byte-range- 540 set. 542 If the last-byte-pos value is absent, or if the value is greater than 543 or equal to the current length of the representation body, last-byte- 544 pos is taken to be equal to one less than the current length of the 545 representation in bytes. 547 By its choice of last-byte-pos, a client can limit the number of 548 bytes retrieved without knowing the size of the representation. 550 suffix-byte-range-spec = "-" suffix-length 551 suffix-length = 1*DIGIT 553 A suffix-byte-range-spec is used to specify the suffix of the 554 representation body, of a length given by the suffix-length value. 555 (That is, this form specifies the last N bytes of a representation.) 556 If the representation is shorter than the specified suffix-length, 557 the entire representation is used. 559 If a syntactically valid byte-range-set includes at least one byte- 560 range-spec whose first-byte-pos is less than the current length of 561 the representation, or at least one suffix-byte-range-spec with a 562 non-zero suffix-length, then the byte-range-set is satisfiable. 563 Otherwise, the byte-range-set is unsatisfiable. If the byte-range- 564 set is unsatisfiable, the server SHOULD return a response with a 416 565 (Requested range not satisfiable) status code. Otherwise, the server 566 SHOULD return a response with a 206 (Partial Content) status code 567 containing the satisfiable ranges of the representation. 569 Examples of byte-ranges-specifier values (assuming a representation 570 of length 10000): 572 o The first 500 bytes (byte offsets 0-499, inclusive): 574 bytes=0-499 576 o The second 500 bytes (byte offsets 500-999, inclusive): 578 bytes=500-999 580 o The final 500 bytes (byte offsets 9500-9999, inclusive): 582 bytes=-500 584 Or: 586 bytes=9500- 588 o The first and last bytes only (bytes 0 and 9999): 590 bytes=0-0,-1 592 o Several legal but not canonical specifications of the second 500 593 bytes (byte offsets 500-999, inclusive): 595 bytes=500-600,601-999 596 bytes=500-700,601-999 598 5.4.2. Range Retrieval Requests 600 The "Range" request-header field defines the GET method (conditional 601 or not) to request one or more sub-ranges of the response 602 representation body, instead of the entire representation body. 604 Range = "Range" ":" OWS Range-v 605 Range-v = byte-ranges-specifier 606 / other-ranges-specifier 607 other-ranges-specifier = other-range-unit "=" other-range-set 608 other-range-set = 1*CHAR 610 A server MAY ignore the Range header field. However, HTTP/1.1 origin 611 servers and intermediate caches ought to support byte ranges when 612 possible, since Range supports efficient recovery from partially 613 failed transfers, and supports efficient partial retrieval of large 614 representations. 616 If the server supports the Range header field and the specified range 617 or ranges are appropriate for the representation: 619 o The presence of a Range header field in an unconditional GET 620 modifies what is returned if the GET is otherwise successful. In 621 other words, the response carries a status code of 206 (Partial 622 Content) instead of 200 (OK). 624 o The presence of a Range header field in a conditional GET (a 625 request using one or both of If-Modified-Since and If-None-Match, 626 or one or both of If-Unmodified-Since and If-Match) modifies what 627 is returned if the GET is otherwise successful and the condition 628 is true. It does not affect the 304 (Not Modified) response 629 returned if the conditional is false. 631 In some cases, it might be more appropriate to use the If-Range 632 header field (see Section 5.3) in addition to the Range header field. 634 If a proxy that supports ranges receives a Range request, forwards 635 the request to an inbound server, and receives an entire 636 representation in reply, it MAY only return the requested range to 637 its client. 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-12 712 (work in progress), October 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-12 (work in 718 progress), October 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 RFC 2616 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 Field Registration 959 (): 961 o Reference RFC 3984, and update header field registrations for 962 headers 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 field 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 D.13. Since draft-ietf-httpbis-p5-range-11 1053 Closed issues: 1055 o : "Caches can't 1056 be required to serve ranges" 1058 Index 1060 2 1061 206 Partial Content (status code) 6 1063 4 1064 416 Requested Range Not Satisfiable (status code) 7 1066 A 1067 Accept-Ranges header 8 1069 C 1070 Content-Range header 8 1072 G 1073 Grammar 1074 Accept-Ranges 8 1075 Accept-Ranges-v 8 1076 acceptable-ranges 8 1077 byte-content-range-spec 8 1078 byte-range-resp-spec 8 1079 byte-range-set 11 1080 byte-range-spec 11 1081 byte-ranges-specifier 11 1082 bytes-unit 5 1083 Content-Range 8 1084 content-range-spec 8 1085 Content-Range-v 8 1086 first-byte-pos 11 1087 If-Range 11 1088 If-Range-v 11 1089 instance-length 8 1090 last-byte-pos 11 1091 other-range-unit 5 1092 Range 13 1093 range-unit 5 1094 ranges-specifier 11 1095 suffix-byte-range-spec 12 1096 suffix-length 12 1098 H 1099 Headers 1100 Accept-Ranges 8 1101 Content-Range 8 1102 If-Range 10 1103 Range 11 1105 I 1106 If-Range header 10 1108 M 1109 Media Type 1110 multipart/byteranges 16 1111 multipart/x-byteranges 19 1112 multipart/byteranges Media Type 16 1113 multipart/x-byteranges Media Type 19 1115 R 1116 Range header 11 1118 S 1119 Status Codes 1120 206 Partial Content 6 1121 416 Requested Range Not Satisfiable 7 1123 Authors' Addresses 1125 Roy T. Fielding (editor) 1126 Day Software 1127 23 Corporate Plaza DR, Suite 280 1128 Newport Beach, CA 92660 1129 USA 1131 Phone: +1-949-706-5300 1132 Fax: +1-949-706-5305 1133 EMail: fielding@gbiv.com 1134 URI: http://roy.gbiv.com/ 1135 Jim Gettys 1136 Alcatel-Lucent Bell Labs 1137 21 Oak Knoll Road 1138 Carlisle, MA 01741 1139 USA 1141 EMail: jg@freedesktop.org 1142 URI: http://gettys.wordpress.com/ 1144 Jeffrey C. Mogul 1145 Hewlett-Packard Company 1146 HP Labs, Large Scale Systems Group 1147 1501 Page Mill Road, MS 1177 1148 Palo Alto, CA 94304 1149 USA 1151 EMail: JeffMogul@acm.org 1153 Henrik Frystyk Nielsen 1154 Microsoft Corporation 1155 1 Microsoft Way 1156 Redmond, WA 98052 1157 USA 1159 EMail: henrikn@microsoft.com 1161 Larry Masinter 1162 Adobe Systems, Incorporated 1163 345 Park Ave 1164 San Jose, CA 95110 1165 USA 1167 EMail: LMM@acm.org 1168 URI: http://larry.masinter.net/ 1170 Paul J. Leach 1171 Microsoft Corporation 1172 1 Microsoft Way 1173 Redmond, WA 98052 1175 EMail: paulle@microsoft.com 1176 Tim Berners-Lee 1177 World Wide Web Consortium 1178 MIT Computer Science and Artificial Intelligence Laboratory 1179 The Stata Center, Building 32 1180 32 Vassar Street 1181 Cambridge, MA 02139 1182 USA 1184 EMail: timbl@w3.org 1185 URI: http://www.w3.org/People/Berners-Lee/ 1187 Yves Lafon (editor) 1188 World Wide Web Consortium 1189 W3C / ERCIM 1190 2004, rte des Lucioles 1191 Sophia-Antipolis, AM 06902 1192 France 1194 EMail: ylafon@w3.org 1195 URI: http://www.raubacapeu.net/people/yves/ 1197 Julian F. Reschke (editor) 1198 greenbytes GmbH 1199 Hafenweg 16 1200 Muenster, NW 48155 1201 Germany 1203 Phone: +49 251 2807760 1204 Fax: +49 251 2807761 1205 EMail: julian.reschke@greenbytes.de 1206 URI: http://greenbytes.de/tech/webdav/