idnits 2.17.1 draft-ietf-httpbis-p5-range-16.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 24, 2011) is 4621 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-16 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-16 -- 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: February 25, 2012 J. Mogul 7 HP 8 H. Frystyk 9 Microsoft 10 L. Masinter 11 Adobe 12 P. Leach 13 Microsoft 14 T. Berners-Lee 15 W3C/MIT 16 Y. Lafon, Ed. 17 W3C 18 J. Reschke, Ed. 19 greenbytes 20 August 24, 2011 22 HTTP/1.1, part 5: Range Requests and Partial Responses 23 draft-ietf-httpbis-p5-range-16 25 Abstract 27 The Hypertext Transfer Protocol (HTTP) is an application-level 28 protocol for distributed, collaborative, hypertext 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. 34 Part 5 defines range-specific requests and the rules for constructing 35 and combining responses to those requests. 37 Editorial Note (To be removed by RFC Editor) 39 Discussion of this draft should take place on the HTTPBIS working 40 group mailing list (ietf-http-wg@w3.org), which is archived at 41 . 43 The current issues list is at 44 and related 45 documents (including fancy diffs) can be found at 46 . 48 The changes in this draft are summarized in Appendix D.17. 50 Status of This Memo 52 This Internet-Draft is submitted in full conformance with the 53 provisions of BCP 78 and BCP 79. 55 Internet-Drafts are working documents of the Internet Engineering 56 Task Force (IETF). Note that other groups may also distribute 57 working documents as Internet-Drafts. The list of current Internet- 58 Drafts is at http://datatracker.ietf.org/drafts/current/. 60 Internet-Drafts are draft documents valid for a maximum of six months 61 and may be updated, replaced, or obsoleted by other documents at any 62 time. It is inappropriate to use Internet-Drafts as reference 63 material or to cite them other than as "work in progress." 65 This Internet-Draft will expire on February 25, 2012. 67 Copyright Notice 69 Copyright (c) 2011 IETF Trust and the persons identified as the 70 document authors. All rights reserved. 72 This document is subject to BCP 78 and the IETF Trust's Legal 73 Provisions Relating to IETF Documents 74 (http://trustee.ietf.org/license-info) in effect on the date of 75 publication of this document. Please review these documents 76 carefully, as they describe your rights and restrictions with respect 77 to this document. Code Components extracted from this document must 78 include Simplified BSD License text as described in Section 4.e of 79 the Trust Legal Provisions and are provided without warranty as 80 described in the Simplified BSD License. 82 This document may contain material from IETF Documents or IETF 83 Contributions published or made publicly available before November 84 10, 2008. The person(s) controlling the copyright in some of this 85 material may not have granted the IETF Trust the right to allow 86 modifications of such material outside the IETF Standards Process. 87 Without obtaining an adequate license from the person(s) controlling 88 the copyright in such materials, this document may not be modified 89 outside the IETF Standards Process, and derivative works of it may 90 not be created outside the IETF Standards Process, except to format 91 it for publication as an RFC or to translate it into languages other 92 than English. 94 Table of Contents 96 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 97 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 98 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 99 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6 100 1.2.2. ABNF Rules defined in other Parts of the 101 Specification . . . . . . . . . . . . . . . . . . . . 6 102 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 6 103 2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 6 104 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7 105 3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 7 106 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 7 107 4. Combining Ranges . . . . . . . . . . . . . . . . . . . . . . . 8 108 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 9 109 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 9 110 5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 9 111 5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 12 112 5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 13 113 5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 13 114 5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 15 115 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 116 6.1. Status Code Registration . . . . . . . . . . . . . . . . . 15 117 6.2. Header Field Registration . . . . . . . . . . . . . . . . 16 118 6.3. Range Specifier Registration . . . . . . . . . . . . . . . 16 119 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 120 7.1. Overlapping Ranges . . . . . . . . . . . . . . . . . . . . 17 121 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 122 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 123 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 124 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 125 Appendix A. Internet Media Type multipart/byteranges . . . . . . 18 126 Appendix B. Compatibility with Previous Versions . . . . . . . . 20 127 B.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 20 128 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 21 129 Appendix D. Change Log (to be removed by RFC Editor before 130 publication) . . . . . . . . . . . . . . . . . . . . 22 131 D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 22 132 D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 22 133 D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 22 134 D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 22 135 D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 23 136 D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 23 137 D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 23 138 D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 23 139 D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 24 140 D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 24 141 D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 24 142 D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 24 143 D.13. Since draft-ietf-httpbis-p5-range-11 . . . . . . . . . . . 24 144 D.14. Since draft-ietf-httpbis-p5-range-12 . . . . . . . . . . . 25 145 D.15. Since draft-ietf-httpbis-p5-range-13 . . . . . . . . . . . 25 146 D.16. Since draft-ietf-httpbis-p5-range-14 . . . . . . . . . . . 25 147 D.17. Since draft-ietf-httpbis-p5-range-15 . . . . . . . . . . . 25 148 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 150 1. Introduction 152 HTTP clients often encounter interrupted data transfers as a result 153 of cancelled requests or dropped connections. When a client has 154 stored a partial representation, it is desirable to request the 155 remainder of that representation in a subsequent request rather than 156 transfer the entire representation. There are also a number of Web 157 applications that benefit from being able to request only a subset of 158 a larger representation, such as a single page of a very large 159 document or only part of an image to be rendered by a device with 160 limited local storage. 162 This document defines HTTP/1.1 range requests, partial responses, and 163 the multipart/byteranges media type. The protocol for range requests 164 is an OPTIONAL feature of HTTP, designed so resources or recipients 165 that do not implement this feature can respond as if it is a normal 166 GET request without impacting interoperability. Partial responses 167 are indicated by a distinct status code to not be mistaken for full 168 responses by intermediate caches that might not implement the 169 feature. 171 Although the HTTP range request mechanism is designed to allow for 172 extensible range types, this specification only defines requests for 173 byte ranges. 175 1.1. Requirements 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in [RFC2119]. 181 An implementation is not compliant if it fails to satisfy one or more 182 of the "MUST" or "REQUIRED" level requirements for the protocols it 183 implements. An implementation that satisfies all the "MUST" or 184 "REQUIRED" level and all the "SHOULD" level requirements for its 185 protocols is said to be "unconditionally compliant"; one that 186 satisfies all the "MUST" level requirements but not all the "SHOULD" 187 level requirements for its protocols is said to be "conditionally 188 compliant". 190 1.2. Syntax Notation 192 This specification uses the ABNF syntax defined in Section 1.2 of 193 [Part1] (which extends the syntax defined in [RFC5234] with a list 194 rule). Appendix C shows the collected ABNF, with the list rule 195 expanded. 197 The following core rules are included by reference, as defined in 199 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 200 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 201 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit 202 sequence of data), SP (space), VCHAR (any visible USASCII character), 203 and WSP (whitespace). 205 1.2.1. Core Rules 207 The core rules below are defined in [Part1]: 209 OWS = 210 token = 211 HTTP-date = 213 1.2.2. ABNF Rules defined in other Parts of the Specification 215 The ABNF rules below are defined in other parts: 217 entity-tag = 219 2. Range Units 221 HTTP/1.1 allows a client to request that only part (a range) of the 222 representation be included within the response. HTTP/1.1 uses range 223 units in the Range (Section 5.4) and Content-Range (Section 5.2) 224 header fields. A representation can be broken down into subranges 225 according to various structural units. 227 range-unit = bytes-unit / other-range-unit 228 bytes-unit = "bytes" 229 other-range-unit = token 231 HTTP/1.1 has been designed to allow implementations of applications 232 that do not depend on knowledge of ranges. The only range unit 233 defined by HTTP/1.1 is "bytes". Additional specifiers can be defined 234 as described in Section 2.1. 236 If a range unit is not understood in a request, a server MUST ignore 237 the whole Range header field (Section 5.4). If a range unit is not 238 understood in a response, an intermediary SHOULD pass the response to 239 the client; a client MUST fail. 241 2.1. Range Specifier Registry 243 The HTTP Range Specifier Registry defines the name space for the 244 range specifier names. 246 Registrations MUST include the following fields: 248 o Name 250 o Description 252 o Pointer to specification text 254 Values to be added to this name space are subject to IETF review 255 ([RFC5226], Section 4.1). 257 The registry itself is maintained at 258 . 260 3. Status Code Definitions 262 3.1. 206 Partial Content 264 The server has fulfilled the partial GET request for the resource. 265 The request MUST have included a Range header field (Section 5.4) 266 indicating the desired range, and MAY have included an If-Range 267 header field (Section 5.3) to make the request conditional. 269 The response MUST include the following header fields: 271 o Either a Content-Range header field (Section 5.2) indicating the 272 range included with this response, or a multipart/byteranges 273 Content-Type including Content-Range fields for each part. If a 274 Content-Length header field is present in the response, its value 275 MUST match the actual number of octets transmitted in the message- 276 body. 278 o Date 280 o Cache-Control, ETag, Expires, Content-Location, Last-Modified, 281 and/or Vary, if the header field would have been sent in a 200 282 response to the same request 284 If the 206 response is the result of an If-Range request, the 285 response SHOULD NOT include other representation header fields. 286 Otherwise, the response MUST include all of the representation header 287 fields that would have been returned with a 200 (OK) response to the 288 same request. 290 3.2. 416 Requested Range Not Satisfiable 292 A server SHOULD return a response with this status code if a request 293 included a Range header field (Section 5.4), and none of the ranges- 294 specifier values in this field overlap the current extent of the 295 selected resource, and the request did not include an If-Range header 296 field (Section 5.3). (For byte-ranges, this means that the first- 297 byte-pos of all of the byte-range-spec values were greater than the 298 current length of the selected resource.) 300 When this status code is returned for a byte-range request, the 301 response SHOULD include a Content-Range header field specifying the 302 current length of the representation (see Section 5.2). This 303 response MUST NOT use the multipart/byteranges content-type. 305 4. Combining Ranges 307 A response might transfer only a subrange of a representation if the 308 connection closed prematurely or if the request used one or more 309 Range specifications. After several such transfers, a client might 310 have received several ranges of the same representation. These 311 ranges can only be safely combined if they all have in common the 312 same strong validator, where "strong validator" is defined to be 313 either an entity-tag that is not marked as weak (Section 2.3 of 314 [Part4]) or, if no entity-tag is provided, a Last-Modified value that 315 is strong in the sense defined by Section 2.2.2 of [Part4]. 317 When a client receives an incomplete 200 (OK) or 206 (Partial 318 Content) response and already has one or more stored responses for 319 the same method and effective request URI, all of the stored 320 responses with the same strong validator MAY be combined with the 321 partial content in this new response. If none of the stored 322 responses contain the same strong validator, then this new response 323 corresponds to a new representation and MUST NOT be combined with the 324 existing stored responses. 326 If the new response is an incomplete 200 (OK) response, then the 327 header fields of that new response are used for any combined response 328 and replace those of the matching stored responses. 330 If the new response is a 206 (Partial Content) response and at least 331 one of the matching stored responses is a 200 (OK), then the combined 332 response header fields consist of the most recent 200 response's 333 header fields. If all of the matching stored responses are 206 334 responses, then the stored response with the most header fields is 335 used as the source of header fields for the combined response, except 336 that the client MUST use other header fields provided in the new 337 response, aside from Content-Range, to replace all instances of the 338 corresponding header fields in the stored response. 340 The combined response message-body consists of the union of partial 341 content ranges in the new response and each of the selected 342 responses. If the union consists of the entire range of the 343 representation, then the combined response MUST be recorded as a 344 complete 200 (OK) response with a Content-Length header field that 345 reflects the complete length. Otherwise, the combined response(s) 346 MUST include a Content-Range header field describing the included 347 range(s) and be recorded as incomplete. If the union consists of a 348 discontinuous range of the representation, then the client MAY store 349 it as either a multipart range response or as multiple 206 responses 350 with one continuous range each. 352 5. Header Field Definitions 354 This section defines the syntax and semantics of HTTP/1.1 header 355 fields related to range requests and partial responses. 357 5.1. Accept-Ranges 359 The "Accept-Ranges" header field allows a resource to indicate its 360 acceptance of range requests. 362 Accept-Ranges = acceptable-ranges 363 acceptable-ranges = 1#range-unit / "none" 365 Origin servers that accept byte-range requests MAY send 367 Accept-Ranges: bytes 369 but are not required to do so. Clients MAY generate range requests 370 without having received this header field for the resource involved. 371 Range units are defined in Section 2. 373 Servers that do not accept any kind of range request for a resource 374 MAY send 376 Accept-Ranges: none 378 to advise the client not to attempt a range request. 380 5.2. Content-Range 382 The "Content-Range" header field is sent with a partial 383 representation to specify where in the full representation the 384 payload body is intended to be applied. 386 Range units are defined in Section 2. 388 Content-Range = byte-content-range-spec 389 / other-content-range-spec 391 byte-content-range-spec = bytes-unit SP 392 byte-range-resp-spec "/" 393 ( instance-length / "*" ) 395 byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) 396 / "*" 398 instance-length = 1*DIGIT 400 other-content-range-spec = other-range-unit SP 401 other-range-resp-spec 402 other-range-resp-spec = *CHAR 404 The header field SHOULD indicate the total length of the full 405 representation, unless this length is unknown or difficult to 406 determine. The asterisk "*" character means that the instance-length 407 is unknown at the time when the response was generated. 409 Unlike byte-ranges-specifier values (see Section 5.4.1), a byte- 410 range-resp-spec MUST only specify one range, and MUST contain 411 absolute byte positions for both the first and last byte of the 412 range. 414 A byte-content-range-spec with a byte-range-resp-spec whose last- 415 byte-pos value is less than its first-byte-pos value, or whose 416 instance-length value is less than or equal to its last-byte-pos 417 value, is invalid. The recipient of an invalid byte-content-range- 418 spec MUST ignore it and any content transferred along with it. 420 In the case of a byte range request: A server sending a response with 421 status code 416 (Requested range not satisfiable) SHOULD include a 422 Content-Range field with a byte-range-resp-spec of "*". The 423 instance-length specifies the current length of the selected 424 resource. A response with status code 206 (Partial Content) MUST NOT 425 include a Content-Range field with a byte-range-resp-spec of "*". 427 Examples of byte-content-range-spec values, assuming that the 428 representation contains a total of 1234 bytes: 430 o The first 500 bytes: 432 bytes 0-499/1234 434 o The second 500 bytes: 436 bytes 500-999/1234 438 o All except for the first 500 bytes: 440 bytes 500-1233/1234 442 o The last 500 bytes: 444 bytes 734-1233/1234 446 When an HTTP message includes the content of a single range (for 447 example, a response to a request for a single range, or to a request 448 for a set of ranges that overlap without any holes), this content is 449 transmitted with a Content-Range header field, and a Content-Length 450 header field showing the number of bytes actually transferred. For 451 example, 453 HTTP/1.1 206 Partial Content 454 Date: Wed, 15 Nov 1995 06:25:24 GMT 455 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 456 Content-Range: bytes 21010-47021/47022 457 Content-Length: 26012 458 Content-Type: image/gif 460 When an HTTP message includes the content of multiple ranges (for 461 example, a response to a request for multiple non-overlapping 462 ranges), these are transmitted as a multipart message. The multipart 463 media type used for this purpose is "multipart/byteranges" as defined 464 in Appendix A. 466 A response to a request for a single range MUST NOT be sent using the 467 multipart/byteranges media type. A response to a request for 468 multiple ranges, whose result is a single range, MAY be sent as a 469 multipart/byteranges media type with one part. A client that cannot 470 decode a multipart/byteranges message MUST NOT ask for multiple 471 ranges in a single request. 473 When a client requests multiple ranges in one request, the server 474 SHOULD return them in the order that they appeared in the request. 476 If the server ignores a byte-range-spec because it is syntactically 477 invalid, the server SHOULD treat the request as if the invalid Range 478 header field did not exist. (Normally, this means return a 200 479 response containing the full representation). 481 If the server receives a request (other than one including an If- 482 Range header field) with an unsatisfiable Range header field (that 483 is, all of whose byte-range-spec values have a first-byte-pos value 484 greater than the current length of the selected resource), it SHOULD 485 return a response code of 416 (Requested range not satisfiable) 486 (Section 3.2). 488 Note: Clients cannot depend on servers to send a 416 (Requested 489 range not satisfiable) response instead of a 200 (OK) response for 490 an unsatisfiable Range header field, since not all servers 491 implement this header field. 493 5.3. If-Range 495 If a client has a partial copy of a representation and wishes to have 496 an up-to-date copy of the entire representation, it could use the 497 Range header field with a conditional GET (using either or both of 498 If-Unmodified-Since and If-Match.) However, if the condition fails 499 because the representation has been modified, the client would then 500 have to make a second request to obtain the entire current 501 representation. 503 The "If-Range" header field allows a client to "short-circuit" the 504 second request. Informally, its meaning is "if the representation is 505 unchanged, send me the part(s) that I am missing; otherwise, send me 506 the entire new representation". 508 If-Range = entity-tag / HTTP-date 510 Clients MUST NOT use an entity-tag marked as weak in an If-Range 511 field value and MUST NOT use a Last-Modified date in an If-Range 512 field value unless it has no entity-tag for the representation and 513 the Last-Modified date it does have for the representation is strong 514 in the sense defined by Section 2.2.2 of [Part4]. 516 A server that evaluates a conditional range request that is 517 applicable to one of its representations MUST evaluate the condition 518 as false if the entity-tag used as a validator is marked as weak or, 519 when an HTTP-date is used as the validator, if the date value is not 520 strong in the sense defined by Section 2.2.2 of [Part4]. (A server 521 can distinguish between a valid HTTP-date and any form of entity-tag 522 by examining the first two characters.) 524 The If-Range header field SHOULD only be sent by clients together 525 with a Range header field. The If-Range header field MUST be ignored 526 if it is received in a request that does not include a Range header 527 field. The If-Range header field MUST be ignored by a server that 528 does not support the sub-range operation. 530 If the validator given in the If-Range header field matches the 531 current validator for the selected representation of the target 532 resource, then the server SHOULD send the specified sub-range of the 533 representation using a 206 (Partial Content) response. If the 534 validator does not match, then the server SHOULD send the entire 535 representation using a 200 (OK) response. 537 5.4. Range 539 5.4.1. Byte Ranges 541 Since all HTTP representations are transferred as sequences of bytes, 542 the concept of a byte range is meaningful for any HTTP 543 representation. (However, not all clients and servers need to 544 support byte-range operations.) 546 Byte range specifications in HTTP apply to the sequence of bytes in 547 the representation body (not necessarily the same as the message- 548 body). 550 A byte range operation MAY specify a single range of bytes, or a set 551 of ranges within a single representation. 553 byte-ranges-specifier = bytes-unit "=" byte-range-set 554 byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec ) 555 byte-range-spec = first-byte-pos "-" [ last-byte-pos ] 556 first-byte-pos = 1*DIGIT 557 last-byte-pos = 1*DIGIT 559 The first-byte-pos value in a byte-range-spec gives the byte-offset 560 of the first byte in a range. The last-byte-pos value gives the 561 byte-offset of the last byte in the range; that is, the byte 562 positions specified are inclusive. Byte offsets start at zero. 564 If the last-byte-pos value is present, it MUST be greater than or 565 equal to the first-byte-pos in that byte-range-spec, or the byte- 566 range-spec is syntactically invalid. The recipient of a byte-range- 567 set that includes one or more syntactically invalid byte-range-spec 568 values MUST ignore the header field that includes that byte-range- 569 set. 571 If the last-byte-pos value is absent, or if the value is greater than 572 or equal to the current length of the representation body, last-byte- 573 pos is taken to be equal to one less than the current length of the 574 representation in bytes. 576 By its choice of last-byte-pos, a client can limit the number of 577 bytes retrieved without knowing the size of the representation. 579 suffix-byte-range-spec = "-" suffix-length 580 suffix-length = 1*DIGIT 582 A suffix-byte-range-spec is used to specify the suffix of the 583 representation body, of a length given by the suffix-length value. 584 (That is, this form specifies the last N bytes of a representation.) 585 If the representation is shorter than the specified suffix-length, 586 the entire representation is used. 588 If a syntactically valid byte-range-set includes at least one byte- 589 range-spec whose first-byte-pos is less than the current length of 590 the representation, or at least one suffix-byte-range-spec with a 591 non-zero suffix-length, then the byte-range-set is satisfiable. 592 Otherwise, the byte-range-set is unsatisfiable. If the byte-range- 593 set is unsatisfiable, the server SHOULD return a response with a 416 594 (Requested range not satisfiable) status code. Otherwise, the server 595 SHOULD return a response with a 206 (Partial Content) status code 596 containing the satisfiable ranges of the representation. 598 Examples of byte-ranges-specifier values (assuming a representation 599 of length 10000): 601 o The first 500 bytes (byte offsets 0-499, inclusive): 603 bytes=0-499 605 o The second 500 bytes (byte offsets 500-999, inclusive): 607 bytes=500-999 609 o The final 500 bytes (byte offsets 9500-9999, inclusive): 611 bytes=-500 613 Or: 615 bytes=9500- 617 o The first and last bytes only (bytes 0 and 9999): 619 bytes=0-0,-1 621 o Several legal but not canonical specifications of the second 500 622 bytes (byte offsets 500-999, inclusive): 624 bytes=500-600,601-999 625 bytes=500-700,601-999 627 5.4.2. Range Retrieval Requests 629 The "Range" header field defines the GET method (conditional or not) 630 to request one or more sub-ranges of the response representation 631 body, instead of the entire representation body. 633 Range = byte-ranges-specifier / other-ranges-specifier 634 other-ranges-specifier = other-range-unit "=" other-range-set 635 other-range-set = 1*CHAR 637 A server MAY ignore the Range header field. However, origin servers 638 and intermediate caches ought to support byte ranges when possible, 639 since Range supports efficient recovery from partially failed 640 transfers, and supports efficient partial retrieval of large 641 representations. 643 If the server supports the Range header field and the specified range 644 or ranges are appropriate for the representation: 646 o The presence of a Range header field in an unconditional GET 647 modifies what is returned if the GET is otherwise successful. In 648 other words, the response carries a status code of 206 (Partial 649 Content) instead of 200 (OK). 651 o The presence of a Range header field in a conditional GET (a 652 request using one or both of If-Modified-Since and If-None-Match, 653 or one or both of If-Unmodified-Since and If-Match) modifies what 654 is returned if the GET is otherwise successful and the condition 655 is true. It does not affect the 304 (Not Modified) response 656 returned if the conditional is false. 658 In some cases, it might be more appropriate to use the If-Range 659 header field (see Section 5.3) in addition to the Range header field. 661 If a proxy that supports ranges receives a Range request, forwards 662 the request to an inbound server, and receives an entire 663 representation in reply, it MAY only return the requested range to 664 its client. 666 6. IANA Considerations 668 6.1. Status Code Registration 670 The HTTP Status Code Registry located at 671 shall be updated 672 with the registrations below: 674 +-------+---------------------------------+-------------+ 675 | Value | Description | Reference | 676 +-------+---------------------------------+-------------+ 677 | 206 | Partial Content | Section 3.1 | 678 | 416 | Requested Range Not Satisfiable | Section 3.2 | 679 +-------+---------------------------------+-------------+ 681 6.2. Header Field Registration 683 The Message Header Field Registry located at shall be 685 updated with the permanent registrations below (see [RFC3864]): 687 +-------------------+----------+----------+-------------+ 688 | Header Field Name | Protocol | Status | Reference | 689 +-------------------+----------+----------+-------------+ 690 | Accept-Ranges | http | standard | Section 5.1 | 691 | Content-Range | http | standard | Section 5.2 | 692 | If-Range | http | standard | Section 5.3 | 693 | Range | http | standard | Section 5.4 | 694 +-------------------+----------+----------+-------------+ 696 The change controller is: "IETF (iesg@ietf.org) - Internet 697 Engineering Task Force". 699 6.3. Range Specifier Registration 701 The registration procedure for HTTP Range Specifiers is defined by 702 Section 2.1 of this document. 704 The HTTP Range Specifier Registry shall be created at 705 and be 706 populated with the registrations below: 708 +----------------------+-------------------+----------------------+ 709 | Range Specifier Name | Description | Reference | 710 +----------------------+-------------------+----------------------+ 711 | bytes | a range of octets | (this specification) | 712 +----------------------+-------------------+----------------------+ 714 The change controller is: "IETF (iesg@ietf.org) - Internet 715 Engineering Task Force". 717 7. Security Considerations 719 This section is meant to inform application developers, information 720 providers, and users of the security limitations in HTTP/1.1 as 721 described by this document. The discussion does not include 722 definitive solutions to the problems revealed, though it does make 723 some suggestions for reducing security risks. 725 7.1. Overlapping Ranges 727 Range requests containing overlapping ranges may lead to the 728 situation where a server is sending far more data than the size of 729 the complete resource representation. 731 8. Acknowledgments 733 See Section 12 of [Part1]. 735 9. References 737 9.1. Normative References 739 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 740 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 741 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, 742 and Message Parsing", draft-ietf-httpbis-p1-messaging-16 743 (work in progress), August 2011. 745 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 746 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 747 and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional 748 Requests", draft-ietf-httpbis-p4-conditional-16 (work in 749 progress), August 2011. 751 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 752 Extensions (MIME) Part Two: Media Types", RFC 2046, 753 November 1996. 755 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 756 Requirement Levels", BCP 14, RFC 2119, March 1997. 758 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 759 Specifications: ABNF", STD 68, RFC 5234, January 2008. 761 9.2. Informative References 763 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 764 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 765 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 767 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 768 Procedures for Message Header Fields", BCP 90, RFC 3864, 769 September 2004. 771 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 772 Registration Procedures", BCP 13, RFC 4288, December 2005. 774 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 775 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 776 May 2008. 778 Appendix A. Internet Media Type multipart/byteranges 780 When an HTTP 206 (Partial Content) response message includes the 781 content of multiple ranges (a response to a request for multiple non- 782 overlapping ranges), these are transmitted as a multipart message- 783 body ([RFC2046], Section 5.1). The media type for this purpose is 784 called "multipart/byteranges". The following is to be registered 785 with IANA [RFC4288]. 787 Note: Despite the name "multipart/byteranges" is not limited to 788 the byte ranges only. 790 The multipart/byteranges media type includes one or more parts, each 791 with its own Content-Type and Content-Range fields. The required 792 boundary parameter specifies the boundary string used to separate 793 each body-part. 795 Type name: multipart 797 Subtype name: byteranges 799 Required parameters: boundary 801 Optional parameters: none 803 Encoding considerations: only "7bit", "8bit", or "binary" are 804 permitted 806 Security considerations: none 808 Interoperability considerations: none 810 Published specification: This specification (see Appendix A). 812 Applications that use this media type: 814 Additional information: 816 Magic number(s): none 818 File extension(s): none 820 Macintosh file type code(s): none 822 Person and email address to contact for further information: See 823 Authors Section. 825 Intended usage: COMMON 827 Restrictions on usage: none 829 Author/Change controller: IESG 831 For example: 833 HTTP/1.1 206 Partial Content 834 Date: Wed, 15 Nov 1995 06:25:24 GMT 835 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 836 Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES 838 --THIS_STRING_SEPARATES 839 Content-type: application/pdf 840 Content-range: bytes 500-999/8000 842 ...the first range... 843 --THIS_STRING_SEPARATES 844 Content-type: application/pdf 845 Content-range: bytes 7000-7999/8000 847 ...the second range 848 --THIS_STRING_SEPARATES-- 850 Other example: 852 HTTP/1.1 206 Partial Content 853 Date: Tue, 14 Nov 1995 06:25:24 GMT 854 Last-Modified: Tue, 14 July 04:58:08 GMT 855 Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES 857 --THIS_STRING_SEPARATES 858 Content-type: video/example 859 Content-range: exampleunit 1.2-4.3/25 861 ...the first range... 862 --THIS_STRING_SEPARATES 863 Content-type: video/example 864 Content-range: exampleunit 11.2-14.3/25 866 ...the second range 867 --THIS_STRING_SEPARATES-- 869 Notes: 871 1. Additional CRLFs MAY precede the first boundary string in the 872 body. 874 2. Although [RFC2046] permits the boundary string to be quoted, some 875 existing implementations handle a quoted boundary string 876 incorrectly. 878 3. A number of browsers and servers were coded to an early draft of 879 the byteranges specification to use a media type of multipart/ 880 x-byteranges, which is almost, but not quite compatible with the 881 version documented in HTTP/1.1. 883 Appendix B. Compatibility with Previous Versions 885 B.1. Changes from RFC 2616 887 Clarify that it is not ok to use a weak validator in a 206 response. 888 (Section 3.1) 890 Change ABNF productions for header fields to only define the field 891 value. (Section 5) 893 Clarify that multipart/byteranges can consist of a single part. 894 (Appendix A) 896 Appendix C. Collected ABNF 898 Accept-Ranges = acceptable-ranges 900 Content-Range = byte-content-range-spec / other-content-range-spec 902 HTTP-date = 904 If-Range = entity-tag / HTTP-date 906 OWS = 908 Range = byte-ranges-specifier / other-ranges-specifier 910 acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS 911 range-unit ] ) ) / "none" 913 byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" ( 914 instance-length / "*" ) 915 byte-range-resp-spec = ( first-byte-pos "-" last-byte-pos ) / "*" 916 byte-range-set = ( *( "," OWS ) byte-range-spec ) / ( 917 suffix-byte-range-spec *( OWS "," [ ( OWS byte-range-spec ) / 918 suffix-byte-range-spec ] ) ) 919 byte-range-spec = first-byte-pos "-" [ last-byte-pos ] 920 byte-ranges-specifier = bytes-unit "=" byte-range-set 921 bytes-unit = "bytes" 923 entity-tag = 925 first-byte-pos = 1*DIGIT 927 instance-length = 1*DIGIT 929 last-byte-pos = 1*DIGIT 931 other-content-range-spec = other-range-unit SP other-range-resp-spec 932 other-range-resp-spec = *CHAR 933 other-range-set = 1*CHAR 934 other-range-unit = token 935 other-ranges-specifier = other-range-unit "=" other-range-set 937 range-unit = bytes-unit / other-range-unit 939 suffix-byte-range-spec = "-" suffix-length 940 suffix-length = 1*DIGIT 942 token = 943 ABNF diagnostics: 945 ; Accept-Ranges defined but not used 946 ; Content-Range defined but not used 947 ; If-Range defined but not used 948 ; Range defined but not used 950 Appendix D. Change Log (to be removed by RFC Editor before publication) 952 D.1. Since RFC 2616 954 Extracted relevant partitions from [RFC2616]. 956 D.2. Since draft-ietf-httpbis-p5-range-00 958 Closed issues: 960 o : "Cache 961 validators in 206 responses" 962 () 964 o : "Normative and 965 Informative references" 967 o : "Normative up- 968 to-date references" 970 D.3. Since draft-ietf-httpbis-p5-range-01 972 Closed issues: 974 o : "Updating to 975 RFC4288" 977 Ongoing work on ABNF conversion 978 (): 980 o Add explicit references to BNF syntax and rules imported from 981 other parts of the specification. 983 D.4. Since draft-ietf-httpbis-p5-range-02 985 Ongoing work on IANA Message Header Field Registration 986 (): 988 o Reference RFC 3984, and update header field registrations for 989 headers defined in this document. 991 D.5. Since draft-ietf-httpbis-p5-range-03 993 None. 995 D.6. Since draft-ietf-httpbis-p5-range-04 997 Closed issues: 999 o : "multipart/ 1000 byteranges minimum number of parts" 1002 Ongoing work on ABNF conversion 1003 (): 1005 o Use "/" instead of "|" for alternatives. 1007 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 1008 whitespace ("OWS") and required whitespace ("RWS"). 1010 o Rewrite ABNFs to spell out whitespace rules, factor out header 1011 field value format definitions. 1013 D.7. Since draft-ietf-httpbis-p5-range-05 1015 Closed issues: 1017 o : "State base 1018 for *-byte-pos and suffix-length" 1020 Ongoing work on Custom Ranges 1021 (): 1023 o Remove bias in favor of byte ranges; allow custom ranges in ABNF. 1025 Final work on ABNF conversion 1026 (): 1028 o Add appendix containing collected and expanded ABNF, reorganize 1029 ABNF introduction. 1031 D.8. Since draft-ietf-httpbis-p5-range-06 1033 Closed issues: 1035 o : "base for 1036 numeric protocol elements" 1038 D.9. Since draft-ietf-httpbis-p5-range-07 1040 Closed issues: 1042 o Fixed discrepancy in the If-Range definition about allowed 1043 validators. 1045 o : "multipart/ 1046 byteranges for custom range units" 1048 o : "range unit 1049 missing from other-ranges-specifier in Range header" 1051 o : "move IANA 1052 registrations for optional status codes" 1054 D.10. Since draft-ietf-httpbis-p5-range-08 1056 No significant changes. 1058 D.11. Since draft-ietf-httpbis-p5-range-09 1060 No significant changes. 1062 D.12. Since draft-ietf-httpbis-p5-range-10 1064 Closed issues: 1066 o : "Clarify 1067 'Requested Variant'" 1069 o : "Clarify 1070 entity / representation / variant terminology" 1072 o : "consider 1073 removing the 'changes from 2068' sections" 1075 Ongoing work on Custom Ranges 1076 (): 1078 o Add IANA registry. 1080 D.13. Since draft-ietf-httpbis-p5-range-11 1082 Closed issues: 1084 o : "Caches can't 1085 be required to serve ranges" 1087 D.14. Since draft-ietf-httpbis-p5-range-12 1089 Closed issues: 1091 o : "Header 1092 Classification" 1094 D.15. Since draft-ietf-httpbis-p5-range-13 1096 Closed issues: 1098 o : "untangle 1099 ABNFs for header fields" 1101 D.16. Since draft-ietf-httpbis-p5-range-14 1103 None. 1105 D.17. Since draft-ietf-httpbis-p5-range-15 1107 Closed issues: 1109 o : "Security 1110 consideration: range flooding" 1112 Index 1114 2 1115 206 Partial Content (status code) 7 1117 4 1118 416 Requested Range Not Satisfiable (status code) 7 1120 A 1121 Accept-Ranges header field 9 1123 C 1124 Content-Range header field 9 1126 G 1127 Grammar 1128 Accept-Ranges 9 1129 acceptable-ranges 9 1130 byte-content-range-spec 10 1131 byte-range-resp-spec 10 1132 byte-range-set 13 1133 byte-range-spec 13 1134 byte-ranges-specifier 13 1135 bytes-unit 6 1136 Content-Range 10 1137 first-byte-pos 13 1138 If-Range 12 1139 instance-length 10 1140 last-byte-pos 13 1141 other-range-unit 6 1142 Range 15 1143 range-unit 6 1144 ranges-specifier 13 1145 suffix-byte-range-spec 14 1146 suffix-length 14 1148 H 1149 Header Fields 1150 Accept-Ranges 9 1151 Content-Range 9 1152 If-Range 12 1153 Range 13 1155 I 1156 If-Range header field 12 1158 M 1159 Media Type 1160 multipart/byteranges 18 1161 multipart/x-byteranges 20 1162 multipart/byteranges Media Type 18 1163 multipart/x-byteranges Media Type 20 1165 R 1166 Range header field 13 1168 S 1169 Status Codes 1170 206 Partial Content 7 1171 416 Requested Range Not Satisfiable 7 1173 Authors' Addresses 1175 Roy T. Fielding (editor) 1176 Adobe Systems Incorporated 1177 345 Park Ave 1178 San Jose, CA 95110 1179 USA 1181 EMail: fielding@gbiv.com 1182 URI: http://roy.gbiv.com/ 1184 Jim Gettys 1185 Alcatel-Lucent Bell Labs 1186 21 Oak Knoll Road 1187 Carlisle, MA 01741 1188 USA 1190 EMail: jg@freedesktop.org 1191 URI: http://gettys.wordpress.com/ 1193 Jeffrey C. Mogul 1194 Hewlett-Packard Company 1195 HP Labs, Large Scale Systems Group 1196 1501 Page Mill Road, MS 1177 1197 Palo Alto, CA 94304 1198 USA 1200 EMail: JeffMogul@acm.org 1202 Henrik Frystyk Nielsen 1203 Microsoft Corporation 1204 1 Microsoft Way 1205 Redmond, WA 98052 1206 USA 1208 EMail: henrikn@microsoft.com 1209 Larry Masinter 1210 Adobe Systems Incorporated 1211 345 Park Ave 1212 San Jose, CA 95110 1213 USA 1215 EMail: LMM@acm.org 1216 URI: http://larry.masinter.net/ 1218 Paul J. Leach 1219 Microsoft Corporation 1220 1 Microsoft Way 1221 Redmond, WA 98052 1223 EMail: paulle@microsoft.com 1225 Tim Berners-Lee 1226 World Wide Web Consortium 1227 MIT Computer Science and Artificial Intelligence Laboratory 1228 The Stata Center, Building 32 1229 32 Vassar Street 1230 Cambridge, MA 02139 1231 USA 1233 EMail: timbl@w3.org 1234 URI: http://www.w3.org/People/Berners-Lee/ 1236 Yves Lafon (editor) 1237 World Wide Web Consortium 1238 W3C / ERCIM 1239 2004, rte des Lucioles 1240 Sophia-Antipolis, AM 06902 1241 France 1243 EMail: ylafon@w3.org 1244 URI: http://www.raubacapeu.net/people/yves/ 1245 Julian F. Reschke (editor) 1246 greenbytes GmbH 1247 Hafenweg 16 1248 Muenster, NW 48155 1249 Germany 1251 Phone: +49 251 2807760 1252 Fax: +49 251 2807761 1253 EMail: julian.reschke@greenbytes.de 1254 URI: http://greenbytes.de/tech/webdav/