idnits 2.17.1 draft-ietf-httpbis-p5-range-13.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 (March 14, 2011) is 4790 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-13 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-13 -- 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: September 15, 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 March 14, 2011 22 HTTP/1.1, part 5: Range Requests and Partial Responses 23 draft-ietf-httpbis-p5-range-13 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.14. 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 September 15, 2011. 63 Copyright Notice 65 Copyright (c) 2011 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 D.14. Since draft-ietf-httpbis-p5-range-12 . . . . . . . . . . . 23 140 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 142 1. Introduction 144 HTTP clients often encounter interrupted data transfers as a result 145 of cancelled requests or dropped connections. When a cache has 146 stored a partial representation, it is desirable to request the 147 remainder of that representation in a subsequent request rather than 148 transfer the entire representation. There are also a number of Web 149 applications that benefit from being able to request only a subset of 150 a larger representation, such as a single page of a very large 151 document or only part of an image to be rendered by a device with 152 limited local storage. 154 This document defines HTTP/1.1 range requests, partial responses, and 155 the multipart/byteranges media type. The protocol for range requests 156 is an OPTIONAL feature of HTTP, designed so resources or recipients 157 that do not implement this feature can respond as if it is a normal 158 GET request without impacting interoperability. Partial responses 159 are indicated by a distinct status code to not be mistaken for full 160 responses by intermediate caches that might not implement the 161 feature. 163 Although the HTTP range request mechanism is designed to allow for 164 extensible range types, this specification only defines requests for 165 byte ranges. 167 1.1. Requirements 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in [RFC2119]. 173 An implementation is not compliant if it fails to satisfy one or more 174 of the "MUST" or "REQUIRED" level requirements for the protocols it 175 implements. An implementation that satisfies all the "MUST" or 176 "REQUIRED" level and all the "SHOULD" level requirements for its 177 protocols is said to be "unconditionally compliant"; one that 178 satisfies all the "MUST" level requirements but not all the "SHOULD" 179 level requirements for its protocols is said to be "conditionally 180 compliant". 182 1.2. Syntax Notation 184 This specification uses the ABNF syntax defined in Section 1.2 of 185 [Part1] (which extends the syntax defined in [RFC5234] with a list 186 rule). Appendix C shows the collected ABNF, with the list rule 187 expanded. 189 The following core rules are included by reference, as defined in 191 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 192 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 193 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit 194 sequence of data), SP (space), VCHAR (any visible USASCII character), 195 and WSP (whitespace). 197 1.2.1. Core Rules 199 The core rules below are defined in Section 1.2.2 of [Part1]: 201 token = 202 OWS = 204 1.2.2. ABNF Rules defined in other Parts of the Specification 206 The ABNF rules below are defined in other parts: 208 HTTP-date = 210 entity-tag = 212 2. Range Units 214 HTTP/1.1 allows a client to request that only part (a range of) the 215 representation be included within the response. HTTP/1.1 uses range 216 units in the Range (Section 5.4) and Content-Range (Section 5.2) 217 header fields. A representation can be broken down into subranges 218 according to various structural units. 220 range-unit = bytes-unit / other-range-unit 221 bytes-unit = "bytes" 222 other-range-unit = token 224 HTTP/1.1 has been designed to allow implementations of applications 225 that do not depend on knowledge of ranges. The only range unit 226 defined by HTTP/1.1 is "bytes". Additional specifiers can be defined 227 as described in Section 2.1. 229 If a range unit is not understood in a request, a server MUST ignore 230 the whole Range header field (Section 5.4). If a range unit is not 231 understood in a response, an intermediary SHOULD pass the response to 232 the client; a client MUST fail. 234 2.1. Range Specifier Registry 236 The HTTP Ranger Specifier Registry defines the name space for the 237 range specifier names. 239 Registrations MUST include the following fields: 241 o Name 243 o Description 245 o Pointer to specification text 247 Values to be added to this name space are subject to IETF review 248 ([RFC5226], Section 4.1). 250 The registry itself is maintained at 251 . 253 3. Status Code Definitions 255 3.1. 206 Partial Content 257 The server has fulfilled the partial GET request for the resource. 258 The request MUST have included a Range header field (Section 5.4) 259 indicating the desired range, and MAY have included an If-Range 260 header field (Section 5.3) to make the request conditional. 262 The response MUST include the following header fields: 264 o Either a Content-Range header field (Section 5.2) indicating the 265 range included with this response, or a multipart/byteranges 266 Content-Type including Content-Range fields for each part. If a 267 Content-Length header field is present in the response, its value 268 MUST match the actual number of octets transmitted in the message- 269 body. 271 o Date 273 o Cache-Control, ETag, Expires, Content-Location, Last-Modified, 274 and/or Vary, if the header field would have been sent in a 200 275 response to the same request 277 If the 206 response is the result of an If-Range request, the 278 response SHOULD NOT include other representation header fields. 279 Otherwise, the response MUST include all of the representation header 280 fields that would have been returned with a 200 (OK) response to the 281 same request. 283 A cache MUST NOT combine a 206 response with other previously cached 284 content if the ETag or Last-Modified header fields do not match 285 exactly, see Section 4. 287 A cache that does not support the Range and Content-Range header 288 fields MUST NOT cache 206 (Partial Content) responses. Furthermore, 289 if a response uses a range unit that is not understood by the cache, 290 then it MUST NOT be cached either. 292 3.2. 416 Requested Range Not Satisfiable 294 A server SHOULD return a response with this status code if a request 295 included a Range header field (Section 5.4), and none of the ranges- 296 specifier values in this field overlap the current extent of the 297 selected resource, and the request did not include an If-Range header 298 field (Section 5.3). (For byte-ranges, this means that the first- 299 byte-pos of all of the byte-range-spec values were greater than the 300 current length of the selected resource.) 302 When this status code is returned for a byte-range request, the 303 response SHOULD include a Content-Range header field specifying the 304 current length of the representation (see Section 5.2). This 305 response MUST NOT use the multipart/byteranges content-type. 307 4. Combining Ranges 309 A response might transfer only a subrange of a representation, either 310 because the request included one or more Range specifications, or 311 because a connection closed prematurely. After several such 312 transfers, a cache might have received several ranges of the same 313 representation. 315 If a cache has a stored non-empty set of subranges for a 316 representation, and an incoming response transfers another subrange, 317 the cache MAY combine the new subrange with the existing set if both 318 the following conditions are met: 320 o Both the incoming response and the cache entry have a cache 321 validator. 323 o The two cache validators match using the strong comparison 324 function (see Section 4 of [Part4]). 326 If either requirement is not met, the cache MUST use only the most 327 recent partial response (based on the Date values transmitted with 328 every response, and using the incoming response if these values are 329 equal or missing), and MUST discard the other partial information. 331 5. Header Field Definitions 333 This section defines the syntax and semantics of HTTP/1.1 header 334 fields related to range requests and partial responses. 336 5.1. Accept-Ranges 338 The "Accept-Ranges" header field allows a resource to indicate its 339 acceptance of range requests. 341 Accept-Ranges = "Accept-Ranges" ":" OWS Accept-Ranges-v 342 Accept-Ranges-v = acceptable-ranges 343 acceptable-ranges = 1#range-unit / "none" 345 Origin servers that accept byte-range requests MAY send 347 Accept-Ranges: bytes 349 but are not required to do so. Clients MAY generate range requests 350 without having received this header field for the resource involved. 351 Range units are defined in Section 2. 353 Servers that do not accept any kind of range request for a resource 354 MAY send 356 Accept-Ranges: none 358 to advise the client not to attempt a range request. 360 5.2. Content-Range 362 The "Content-Range" header field is sent with a partial 363 representation to specify where in the full representation the 364 payload body is intended to be applied. 366 Range units are defined in Section 2. 368 Content-Range = "Content-Range" ":" OWS Content-Range-v 369 Content-Range-v = content-range-spec 371 content-range-spec = byte-content-range-spec 372 / other-content-range-spec 373 byte-content-range-spec = bytes-unit SP 374 byte-range-resp-spec "/" 375 ( instance-length / "*" ) 377 byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) 378 / "*" 380 instance-length = 1*DIGIT 382 other-content-range-spec = other-range-unit SP 383 other-range-resp-spec 385 other-range-resp-spec = *CHAR 387 The header field SHOULD indicate the total length of the full 388 representation, unless this length is unknown or difficult to 389 determine. The asterisk "*" character means that the instance-length 390 is unknown at the time when the response was generated. 392 Unlike byte-ranges-specifier values (see Section 5.4.1), a byte- 393 range-resp-spec MUST only specify one range, and MUST contain 394 absolute byte positions for both the first and last byte of the 395 range. 397 A byte-content-range-spec with a byte-range-resp-spec whose last- 398 byte-pos value is less than its first-byte-pos value, or whose 399 instance-length value is less than or equal to its last-byte-pos 400 value, is invalid. The recipient of an invalid byte-content-range- 401 spec MUST ignore it and any content transferred along with it. 403 In the case of a byte range request: A server sending a response with 404 status code 416 (Requested range not satisfiable) SHOULD include a 405 Content-Range field with a byte-range-resp-spec of "*". The 406 instance-length specifies the current length of the selected 407 resource. A response with status code 206 (Partial Content) MUST NOT 408 include a Content-Range field with a byte-range-resp-spec of "*". 410 Examples of byte-content-range-spec values, assuming that the 411 representation contains a total of 1234 bytes: 413 o The first 500 bytes: 415 bytes 0-499/1234 417 o The second 500 bytes: 419 bytes 500-999/1234 421 o All except for the first 500 bytes: 423 bytes 500-1233/1234 425 o The last 500 bytes: 427 bytes 734-1233/1234 429 When an HTTP message includes the content of a single range (for 430 example, a response to a request for a single range, or to a request 431 for a set of ranges that overlap without any holes), this content is 432 transmitted with a Content-Range header field, and a Content-Length 433 header field showing the number of bytes actually transferred. For 434 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 = "If-Range" ":" OWS If-Range-v 492 If-Range-v = entity-tag / HTTP-date 494 If the client has no entity-tag for a representation, but does have a 495 Last-Modified date, it MAY use that date in an If-Range header field. 496 (The server can distinguish between a valid HTTP-date and any form of 497 entity-tag by examining no more than two characters.) The If-Range 498 header field SHOULD only be used together with a Range header field, 499 and MUST be ignored if the request does not include a Range header 500 field, or if the server does not support the sub-range operation. 502 If the entity-tag given in the If-Range header field matches the 503 current cache validator for the representation, then the server 504 SHOULD provide the specified sub-range of the representation using a 505 206 (Partial Content) response. If the cache validator does not 506 match, then the server SHOULD return the entire representation using 507 a 200 (OK) response. 509 5.4. Range 511 5.4.1. Byte Ranges 513 Since all HTTP representations are transferred as sequences of bytes, 514 the concept of a byte range is meaningful for any HTTP 515 representation. (However, not all clients and servers need to 516 support byte-range operations.) 518 Byte range specifications in HTTP apply to the sequence of bytes in 519 the representation body (not necessarily the same as the message- 520 body). 522 A byte range operation MAY specify a single range of bytes, or a set 523 of ranges within a single representation. 525 byte-ranges-specifier = bytes-unit "=" byte-range-set 526 byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec ) 527 byte-range-spec = first-byte-pos "-" [ last-byte-pos ] 528 first-byte-pos = 1*DIGIT 529 last-byte-pos = 1*DIGIT 531 The first-byte-pos value in a byte-range-spec gives the byte-offset 532 of the first byte in a range. The last-byte-pos value gives the 533 byte-offset of the last byte in the range; that is, the byte 534 positions specified are inclusive. Byte offsets start at zero. 536 If the last-byte-pos value is present, it MUST be greater than or 537 equal to the first-byte-pos in that byte-range-spec, or the byte- 538 range-spec is syntactically invalid. The recipient of a byte-range- 539 set that includes one or more syntactically invalid byte-range-spec 540 values MUST ignore the header field that includes that byte-range- 541 set. 543 If the last-byte-pos value is absent, or if the value is greater than 544 or equal to the current length of the representation body, last-byte- 545 pos is taken to be equal to one less than the current length of the 546 representation in bytes. 548 By its choice of last-byte-pos, a client can limit the number of 549 bytes retrieved without knowing the size of the representation. 551 suffix-byte-range-spec = "-" suffix-length 552 suffix-length = 1*DIGIT 554 A suffix-byte-range-spec is used to specify the suffix of the 555 representation body, of a length given by the suffix-length value. 556 (That is, this form specifies the last N bytes of a representation.) 557 If the representation is shorter than the specified suffix-length, 558 the entire representation is used. 560 If a syntactically valid byte-range-set includes at least one byte- 561 range-spec whose first-byte-pos is less than the current length of 562 the representation, or at least one suffix-byte-range-spec with a 563 non-zero suffix-length, then the byte-range-set is satisfiable. 564 Otherwise, the byte-range-set is unsatisfiable. If the byte-range- 565 set is unsatisfiable, the server SHOULD return a response with a 416 566 (Requested range not satisfiable) status code. Otherwise, the server 567 SHOULD return a response with a 206 (Partial Content) status code 568 containing the satisfiable ranges of the representation. 570 Examples of byte-ranges-specifier values (assuming a representation 571 of length 10000): 573 o The first 500 bytes (byte offsets 0-499, inclusive): 575 bytes=0-499 577 o The second 500 bytes (byte offsets 500-999, inclusive): 579 bytes=500-999 581 o The final 500 bytes (byte offsets 9500-9999, inclusive): 583 bytes=-500 585 Or: 587 bytes=9500- 589 o The first and last bytes only (bytes 0 and 9999): 591 bytes=0-0,-1 593 o Several legal but not canonical specifications of the second 500 594 bytes (byte offsets 500-999, inclusive): 596 bytes=500-600,601-999 597 bytes=500-700,601-999 599 5.4.2. Range Retrieval Requests 601 The "Range" header field defines the GET method (conditional or not) 602 to request one or more sub-ranges of the response representation 603 body, instead of the entire representation body. 605 Range = "Range" ":" OWS Range-v 606 Range-v = byte-ranges-specifier 607 / other-ranges-specifier 608 other-ranges-specifier = other-range-unit "=" other-range-set 609 other-range-set = 1*CHAR 611 A server MAY ignore the Range header field. However, HTTP/1.1 origin 612 servers and intermediate caches ought to support byte ranges when 613 possible, since Range supports efficient recovery from partially 614 failed transfers, and supports efficient partial retrieval of large 615 representations. 617 If the server supports the Range header field and the specified range 618 or ranges are appropriate for the representation: 620 o The presence of a Range header field in an unconditional GET 621 modifies what is returned if the GET is otherwise successful. In 622 other words, the response carries a status code of 206 (Partial 623 Content) instead of 200 (OK). 625 o The presence of a Range header field in a conditional GET (a 626 request using one or both of If-Modified-Since and If-None-Match, 627 or one or both of If-Unmodified-Since and If-Match) modifies what 628 is returned if the GET is otherwise successful and the condition 629 is true. It does not affect the 304 (Not Modified) response 630 returned if the conditional is false. 632 In some cases, it might be more appropriate to use the If-Range 633 header field (see Section 5.3) in addition to the Range header field. 635 If a proxy that supports ranges receives a Range request, forwards 636 the request to an inbound server, and receives an entire 637 representation in reply, it MAY only return the requested range to 638 its client. 640 6. IANA Considerations 642 6.1. Status Code Registration 644 The HTTP Status Code Registry located at 645 shall be updated 646 with the registrations below: 648 +-------+---------------------------------+-------------+ 649 | Value | Description | Reference | 650 +-------+---------------------------------+-------------+ 651 | 206 | Partial Content | Section 3.1 | 652 | 416 | Requested Range Not Satisfiable | Section 3.2 | 653 +-------+---------------------------------+-------------+ 655 6.2. Header Field Registration 657 The Message Header Field Registry located at shall be 659 updated with the permanent registrations below (see [RFC3864]): 661 +-------------------+----------+----------+-------------+ 662 | Header Field Name | Protocol | Status | Reference | 663 +-------------------+----------+----------+-------------+ 664 | Accept-Ranges | http | standard | Section 5.1 | 665 | Content-Range | http | standard | Section 5.2 | 666 | If-Range | http | standard | Section 5.3 | 667 | Range | http | standard | Section 5.4 | 668 +-------------------+----------+----------+-------------+ 670 The change controller is: "IETF (iesg@ietf.org) - Internet 671 Engineering Task Force". 673 6.3. Range Specifier Registration 675 The registration procedure for HTTP Range Specifiers is defined by 676 Section 2.1 of this document. 678 The HTTP Range Specifier Registry shall be created at 679 and be 680 populated with the registrations below: 682 +----------------------+-------------------+----------------------+ 683 | Range Specifier Name | Description | Reference | 684 +----------------------+-------------------+----------------------+ 685 | bytes | a range of octets | (this specification) | 686 +----------------------+-------------------+----------------------+ 688 The change controller is: "IETF (iesg@ietf.org) - Internet 689 Engineering Task Force". 691 7. Security Considerations 693 No additional security considerations have been identified beyond 694 those applicable to HTTP in general [Part1]. 696 8. Acknowledgments 698 Most of the specification of ranges is based on work originally done 699 by Ari Luotonen and John Franks, with additional input from Steve 700 Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin 701 Hamilton, Koen Holtman, Shel Kaplan, Paul Leach, Alex Lopez-Ortiz, 702 Larry Masinter, Jeff Mogul, Lou Montulli, David W. Morris, Luigi 703 Rizzo, and Bill Weihl. 705 9. References 707 9.1. Normative References 709 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 710 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 711 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, 712 and Message Parsing", draft-ietf-httpbis-p1-messaging-13 713 (work in progress), March 2011. 715 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 716 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 717 and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional 718 Requests", draft-ietf-httpbis-p4-conditional-13 (work in 719 progress), March 2011. 721 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 722 Extensions (MIME) Part Two: Media Types", RFC 2046, 723 November 1996. 725 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 726 Requirement Levels", BCP 14, RFC 2119, March 1997. 728 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 729 Specifications: ABNF", STD 68, RFC 5234, January 2008. 731 9.2. Informative References 733 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 734 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 735 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 737 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 738 Procedures for Message Header Fields", BCP 90, RFC 3864, 739 September 2004. 741 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 742 Registration Procedures", BCP 13, RFC 4288, December 2005. 744 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 745 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 746 May 2008. 748 Appendix A. Internet Media Type multipart/byteranges 750 When an HTTP 206 (Partial Content) response message includes the 751 content of multiple ranges (a response to a request for multiple non- 752 overlapping ranges), these are transmitted as a multipart message- 753 body ([RFC2046], Section 5.1). The media type for this purpose is 754 called "multipart/byteranges". The following is to be registered 755 with IANA [RFC4288]. 757 Note: Despite the name "multipart/byteranges" is not limited to 758 the byte ranges only. 760 The multipart/byteranges media type includes one or more parts, each 761 with its own Content-Type and Content-Range fields. The required 762 boundary parameter specifies the boundary string used to separate 763 each body-part. 765 Type name: multipart 767 Subtype name: byteranges 769 Required parameters: boundary 771 Optional parameters: none 773 Encoding considerations: only "7bit", "8bit", or "binary" are 774 permitted 776 Security considerations: none 778 Interoperability considerations: none 780 Published specification: This specification (see Appendix A). 782 Applications that use this media type: 784 Additional information: 786 Magic number(s): none 788 File extension(s): none 790 Macintosh file type code(s): none 792 Person and email address to contact for further information: See 793 Authors Section. 795 Intended usage: COMMON 797 Restrictions on usage: none 799 Author/Change controller: IESG 800 For example: 802 HTTP/1.1 206 Partial Content 803 Date: Wed, 15 Nov 1995 06:25:24 GMT 804 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 805 Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES 807 --THIS_STRING_SEPARATES 808 Content-type: application/pdf 809 Content-range: bytes 500-999/8000 811 ...the first range... 812 --THIS_STRING_SEPARATES 813 Content-type: application/pdf 814 Content-range: bytes 7000-7999/8000 816 ...the second range 817 --THIS_STRING_SEPARATES-- 819 Other example: 821 HTTP/1.1 206 Partial Content 822 Date: Tue, 14 Nov 1995 06:25:24 GMT 823 Last-Modified: Tue, 14 July 04:58:08 GMT 824 Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES 826 --THIS_STRING_SEPARATES 827 Content-type: video/example 828 Content-range: exampleunit 1.2-4.3/25 830 ...the first range... 831 --THIS_STRING_SEPARATES 832 Content-type: video/example 833 Content-range: exampleunit 11.2-14.3/25 835 ...the second range 836 --THIS_STRING_SEPARATES-- 838 Notes: 840 1. Additional CRLFs MAY precede the first boundary string in the 841 body. 843 2. Although [RFC2046] permits the boundary string to be quoted, some 844 existing implementations handle a quoted boundary string 845 incorrectly. 847 3. A number of browsers and servers were coded to an early draft of 848 the byteranges specification to use a media type of multipart/ 849 x-byteranges, which is almost, but not quite compatible with the 850 version documented in HTTP/1.1. 852 Appendix B. Compatibility with Previous Versions 854 B.1. Changes from RFC 2616 856 Clarify that it is not ok to use a weak cache validator in a 206 857 response. (Section 3.1) 859 Clarify that multipart/byteranges can consist of a single part. 860 (Appendix A) 862 Appendix C. Collected ABNF 864 Accept-Ranges = "Accept-Ranges:" OWS Accept-Ranges-v 865 Accept-Ranges-v = acceptable-ranges 867 Content-Range = "Content-Range:" OWS Content-Range-v 868 Content-Range-v = content-range-spec 870 HTTP-date = 872 If-Range = "If-Range:" OWS If-Range-v 873 If-Range-v = entity-tag / HTTP-date 875 OWS = 877 Range = "Range:" OWS Range-v 878 Range-v = byte-ranges-specifier / other-ranges-specifier 880 acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS 881 range-unit ] ) ) / "none" 883 byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" ( 884 instance-length / "*" ) 885 byte-range-resp-spec = ( first-byte-pos "-" last-byte-pos ) / "*" 886 byte-range-set = ( *( "," OWS ) byte-range-spec ) / ( 887 suffix-byte-range-spec *( OWS "," [ ( OWS byte-range-spec ) / 888 suffix-byte-range-spec ] ) ) 889 byte-range-spec = first-byte-pos "-" [ last-byte-pos ] 890 byte-ranges-specifier = bytes-unit "=" byte-range-set 891 bytes-unit = "bytes" 893 content-range-spec = byte-content-range-spec / 894 other-content-range-spec 896 entity-tag = 898 first-byte-pos = 1*DIGIT 900 instance-length = 1*DIGIT 902 last-byte-pos = 1*DIGIT 904 other-content-range-spec = other-range-unit SP other-range-resp-spec 905 other-range-resp-spec = *CHAR 906 other-range-set = 1*CHAR 907 other-range-unit = token 908 other-ranges-specifier = other-range-unit "=" other-range-set 910 range-unit = bytes-unit / other-range-unit 912 suffix-byte-range-spec = "-" suffix-length 913 suffix-length = 1*DIGIT 915 token = 917 ABNF diagnostics: 919 ; Accept-Ranges defined but not used 920 ; Content-Range defined but not used 921 ; If-Range defined but not used 922 ; Range defined but not used 924 Appendix D. Change Log (to be removed by RFC Editor before publication) 926 D.1. Since RFC 2616 928 Extracted relevant partitions from [RFC2616]. 930 D.2. Since draft-ietf-httpbis-p5-range-00 932 Closed issues: 934 o : "Cache 935 validators in 206 responses" 936 () 938 o : "Normative and 939 Informative references" 941 o : "Normative up- 942 to-date references" 944 D.3. Since draft-ietf-httpbis-p5-range-01 946 Closed issues: 948 o : "Updating to 949 RFC4288" 951 Ongoing work on ABNF conversion 952 (): 954 o Add explicit references to BNF syntax and rules imported from 955 other parts of the specification. 957 D.4. Since draft-ietf-httpbis-p5-range-02 959 Ongoing work on IANA Message Header Field Registration 960 (): 962 o Reference RFC 3984, and update header field registrations for 963 headers defined in this document. 965 D.5. Since draft-ietf-httpbis-p5-range-03 967 D.6. Since draft-ietf-httpbis-p5-range-04 969 Closed issues: 971 o : "multipart/ 972 byteranges minimum number of parts" 974 Ongoing work on ABNF conversion 975 (): 977 o Use "/" instead of "|" for alternatives. 979 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 980 whitespace ("OWS") and required whitespace ("RWS"). 982 o Rewrite ABNFs to spell out whitespace rules, factor out header 983 field value format definitions. 985 D.7. Since draft-ietf-httpbis-p5-range-05 987 Closed issues: 989 o : "State base 990 for *-byte-pos and suffix-length" 992 Ongoing work on Custom Ranges 993 (): 995 o Remove bias in favor of byte ranges; allow custom ranges in ABNF. 997 Final work on ABNF conversion 998 (): 1000 o Add appendix containing collected and expanded ABNF, reorganize 1001 ABNF introduction. 1003 D.8. Since draft-ietf-httpbis-p5-range-06 1005 Closed issues: 1007 o : "base for 1008 numeric protocol elements" 1010 D.9. Since draft-ietf-httpbis-p5-range-07 1012 Closed issues: 1014 o Fixed discrepancy in the If-Range definition about allowed 1015 validators. 1017 o : "multipart/ 1018 byteranges for custom range units" 1020 o : "range unit 1021 missing from other-ranges-specifier in Range header" 1023 o : "move IANA 1024 registrations for optional status codes" 1026 D.10. Since draft-ietf-httpbis-p5-range-08 1028 No significant changes. 1030 D.11. Since draft-ietf-httpbis-p5-range-09 1032 No significant changes. 1034 D.12. Since draft-ietf-httpbis-p5-range-10 1036 Closed issues: 1038 o : "Clarify 1039 'Requested Variant'" 1041 o : "Clarify 1042 entity / representation / variant terminology" 1044 o : "consider 1045 removing the 'changes from 2068' sections" 1047 Ongoing work on Custom Ranges 1048 (): 1050 o Add IANA registry. 1052 D.13. Since draft-ietf-httpbis-p5-range-11 1054 Closed issues: 1056 o : "Caches can't 1057 be required to serve ranges" 1059 D.14. Since draft-ietf-httpbis-p5-range-12 1061 Closed issues: 1063 o : "Header 1064 Classification" 1066 Index 1068 2 1069 206 Partial Content (status code) 6 1071 4 1072 416 Requested Range Not Satisfiable (status code) 7 1074 A 1075 Accept-Ranges header field 8 1077 C 1078 Content-Range header field 8 1080 G 1081 Grammar 1082 Accept-Ranges 8 1083 Accept-Ranges-v 8 1084 acceptable-ranges 8 1085 byte-content-range-spec 8 1086 byte-range-resp-spec 8 1087 byte-range-set 11 1088 byte-range-spec 11 1089 byte-ranges-specifier 11 1090 bytes-unit 5 1091 Content-Range 8 1092 content-range-spec 8 1093 Content-Range-v 8 1094 first-byte-pos 11 1095 If-Range 11 1096 If-Range-v 11 1097 instance-length 8 1098 last-byte-pos 11 1099 other-range-unit 5 1100 Range 13 1101 range-unit 5 1102 ranges-specifier 11 1103 suffix-byte-range-spec 12 1104 suffix-length 12 1106 H 1107 Header Fields 1108 Accept-Ranges 8 1109 Content-Range 8 1110 If-Range 10 1111 Range 11 1113 I 1114 If-Range header field 10 1116 M 1117 Media Type 1118 multipart/byteranges 16 1119 multipart/x-byteranges 19 1120 multipart/byteranges Media Type 16 1121 multipart/x-byteranges Media Type 19 1123 R 1124 Range header field 11 1126 S 1127 Status Codes 1128 206 Partial Content 6 1129 416 Requested Range Not Satisfiable 7 1131 Authors' Addresses 1133 Roy T. Fielding (editor) 1134 Adobe Systems Incorporated 1135 345 Park Ave 1136 San Jose, CA 95110 1137 USA 1139 EMail: fielding@gbiv.com 1140 URI: http://roy.gbiv.com/ 1142 Jim Gettys 1143 Alcatel-Lucent Bell Labs 1144 21 Oak Knoll Road 1145 Carlisle, MA 01741 1146 USA 1148 EMail: jg@freedesktop.org 1149 URI: http://gettys.wordpress.com/ 1151 Jeffrey C. Mogul 1152 Hewlett-Packard Company 1153 HP Labs, Large Scale Systems Group 1154 1501 Page Mill Road, MS 1177 1155 Palo Alto, CA 94304 1156 USA 1158 EMail: JeffMogul@acm.org 1160 Henrik Frystyk Nielsen 1161 Microsoft Corporation 1162 1 Microsoft Way 1163 Redmond, WA 98052 1164 USA 1166 EMail: henrikn@microsoft.com 1167 Larry Masinter 1168 Adobe Systems Incorporated 1169 345 Park Ave 1170 San Jose, CA 95110 1171 USA 1173 EMail: LMM@acm.org 1174 URI: http://larry.masinter.net/ 1176 Paul J. Leach 1177 Microsoft Corporation 1178 1 Microsoft Way 1179 Redmond, WA 98052 1181 EMail: paulle@microsoft.com 1183 Tim Berners-Lee 1184 World Wide Web Consortium 1185 MIT Computer Science and Artificial Intelligence Laboratory 1186 The Stata Center, Building 32 1187 32 Vassar Street 1188 Cambridge, MA 02139 1189 USA 1191 EMail: timbl@w3.org 1192 URI: http://www.w3.org/People/Berners-Lee/ 1194 Yves Lafon (editor) 1195 World Wide Web Consortium 1196 W3C / ERCIM 1197 2004, rte des Lucioles 1198 Sophia-Antipolis, AM 06902 1199 France 1201 EMail: ylafon@w3.org 1202 URI: http://www.raubacapeu.net/people/yves/ 1203 Julian F. Reschke (editor) 1204 greenbytes GmbH 1205 Hafenweg 16 1206 Muenster, NW 48155 1207 Germany 1209 Phone: +49 251 2807760 1210 Fax: +49 251 2807761 1211 EMail: julian.reschke@greenbytes.de 1212 URI: http://greenbytes.de/tech/webdav/