idnits 2.17.1 draft-ietf-httpbis-p5-range-24.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC2616, but the abstract doesn't seem to mention this, which it should. 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 (September 25, 2013) is 3866 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2616' is defined on line 801, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-24 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-24 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-24 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-24 -- 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 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 6 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) Y. Lafon, Ed. 5 Intended status: Standards Track W3C 6 Expires: March 29, 2014 J. Reschke, Ed. 7 greenbytes 8 September 25, 2013 10 Hypertext Transfer Protocol (HTTP/1.1): Range Requests 11 draft-ietf-httpbis-p5-range-24 13 Abstract 15 The Hypertext Transfer Protocol (HTTP) is an application-level 16 protocol for distributed, collaborative, hypertext information 17 systems. This document defines range requests and the rules for 18 constructing and combining responses to those requests. 20 Editorial Note (To be removed by RFC Editor) 22 Discussion of this draft takes place on the HTTPBIS working group 23 mailing list (ietf-http-wg@w3.org), which is archived at 24 . 26 The current issues list is at 27 and related 28 documents (including fancy diffs) can be found at 29 . 31 The changes in this draft are summarized in Appendix E.5. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on March 29, 2014. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 This document may contain material from IETF Documents or IETF 66 Contributions published or made publicly available before November 67 10, 2008. The person(s) controlling the copyright in some of this 68 material may not have granted the IETF Trust the right to allow 69 modifications of such material outside the IETF Standards Process. 70 Without obtaining an adequate license from the person(s) controlling 71 the copyright in such materials, this document may not be modified 72 outside the IETF Standards Process, and derivative works of it may 73 not be created outside the IETF Standards Process, except to format 74 it for publication as an RFC or to translate it into languages other 75 than English. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4 81 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 82 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 4 83 2.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . . . 5 84 2.2. Other Range Units . . . . . . . . . . . . . . . . . . . . 7 85 2.3. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7 86 3. Range Requests . . . . . . . . . . . . . . . . . . . . . . . . 7 87 3.1. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 7 88 3.2. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 9 89 4. Responses to a Range Request . . . . . . . . . . . . . . . . . 9 90 4.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 10 91 4.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 12 92 4.3. Combining Ranges . . . . . . . . . . . . . . . . . . . . . 14 93 4.4. 416 Range Not Satisfiable . . . . . . . . . . . . . . . . 15 94 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 95 5.1. Range Unit Registry . . . . . . . . . . . . . . . . . . . 15 96 5.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 15 97 5.1.2. Registrations . . . . . . . . . . . . . . . . . . . . 16 98 5.2. Status Code Registration . . . . . . . . . . . . . . . . . 16 99 5.3. Header Field Registration . . . . . . . . . . . . . . . . 16 100 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 101 6.1. Denial of Service Attacks using Range . . . . . . . . . . 17 102 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 103 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 104 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 105 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 106 Appendix A. Internet Media Type multipart/byteranges . . . . . . 18 107 Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 20 108 Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 21 109 Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 21 110 Appendix E. Change Log (to be removed by RFC Editor before 111 publication) . . . . . . . . . . . . . . . . . . . . 23 112 E.1. Since draft-ietf-httpbis-p5-range-19 . . . . . . . . . . . 23 113 E.2. Since draft-ietf-httpbis-p5-range-20 . . . . . . . . . . . 23 114 E.3. Since draft-ietf-httpbis-p5-range-21 . . . . . . . . . . . 23 115 E.4. Since draft-ietf-httpbis-p5-range-22 . . . . . . . . . . . 24 116 E.5. Since draft-ietf-httpbis-p5-range-23 . . . . . . . . . . . 24 117 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 119 1. Introduction 121 Hypertext Transfer Protocol (HTTP) clients often encounter 122 interrupted data transfers as a result of canceled requests or 123 dropped connections. When a client has stored a partial 124 representation, it is desirable to request the remainder of that 125 representation in a subsequent request rather than transfer the 126 entire representation. Likewise, devices with limited local storage 127 might benefit from being able to request only a subset of a larger 128 representation, such as a single page of a very large document, or 129 the dimensions of an embedded image. 131 This document defines HTTP/1.1 range requests, partial responses, and 132 the multipart/byteranges media type. Range requests are an OPTIONAL 133 feature of HTTP, designed so that recipients not implementing this 134 feature (or not supporting it for the target resource) can respond as 135 if it is a normal GET request without impacting interoperability. 136 Partial responses are indicated by a distinct status code to not be 137 mistaken for full responses by caches that might not implement the 138 feature. 140 Although the range request mechanism is designed to allow for 141 extensible range types, this specification only defines requests for 142 byte ranges. 144 1.1. Conformance and Error Handling 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119]. 150 Conformance criteria and considerations regarding error handling are 151 defined in Section 2.5 of [Part1]. 153 1.2. Syntax Notation 155 This specification uses the Augmented Backus-Naur Form (ABNF) 156 notation of [RFC5234] with the list rule extension defined in Section 157 7 of [Part1]. Appendix C describes rules imported from other 158 documents. Appendix D shows the collected ABNF with the list rule 159 expanded. 161 2. Range Units 163 A representation can be partitioned into subranges according to 164 various structural units, depending on the structure inherent in the 165 representation's media type. This "range unit" is used in the 166 Accept-Ranges (Section 2.3) response header field to advertise 167 support for range requests, the Range (Section 3.1) request header 168 field to delineate the parts of a representation that are requested, 169 and the Content-Range (Section 4.2) payload header field to describe 170 which part of a representation is being transferred. 172 range-unit = bytes-unit / other-range-unit 174 2.1. Byte Ranges 176 Since representation data is transferred in payloads as a sequence of 177 octets, a byte range is a meaningful substructure for any 178 representation transferable over HTTP (Section 3 of [Part2]). We 179 define the "bytes" range unit for expressing subranges of the data's 180 octet sequence. 182 bytes-unit = "bytes" 184 A byte range request can specify a single range of bytes, or a set of 185 ranges within a single representation. 187 byte-ranges-specifier = bytes-unit "=" byte-range-set 188 byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec ) 189 byte-range-spec = first-byte-pos "-" [ last-byte-pos ] 190 first-byte-pos = 1*DIGIT 191 last-byte-pos = 1*DIGIT 193 The first-byte-pos value in a byte-range-spec gives the byte-offset 194 of the first byte in a range. The last-byte-pos value gives the 195 byte-offset of the last byte in the range; that is, the byte 196 positions specified are inclusive. Byte offsets start at zero. 198 Examples of byte-ranges-specifier values: 200 o The first 500 bytes (byte offsets 0-499, inclusive): 202 bytes=0-499 204 o The second 500 bytes (byte offsets 500-999, inclusive): 206 bytes=500-999 208 A byte-range-spec is invalid if the last-byte-pos value is present 209 and less than the first-byte-pos. 211 A client can limit the number of bytes requested without knowing the 212 size of the selected representation. If the last-byte-pos value is 213 absent, or if the value is greater than or equal to the current 214 length of the representation data, the byte range is interpreted as 215 the remainder of the representation (i.e., the server replaces the 216 value of last-byte-pos with a value that is one less than the current 217 length of the selected representation). 219 A client can request the last N bytes of the selected representation 220 using a suffix-byte-range-spec. 222 suffix-byte-range-spec = "-" suffix-length 223 suffix-length = 1*DIGIT 225 If the selected representation is shorter than the specified suffix- 226 length, the entire representation is used. 228 Additional examples, assuming a representation of length 10000: 230 o The final 500 bytes (byte offsets 9500-9999, inclusive): 232 bytes=-500 234 Or: 236 bytes=9500- 238 o The first and last bytes only (bytes 0 and 9999): 240 bytes=0-0,-1 242 o Other valid (but not canonical) specifications of the second 500 243 bytes (byte offsets 500-999, inclusive): 245 bytes=500-600,601-999 246 bytes=500-700,601-999 248 If a valid byte-range-set includes at least one byte-range-spec with 249 a first-byte-pos that is less than the current length of the 250 representation, or at least one suffix-byte-range-spec with a non- 251 zero suffix-length, then the byte-range-set is satisfiable. 252 Otherwise, the byte-range-set is unsatisfiable. 254 In the byte range syntax, first-byte-pos, last-byte-pos, and suffix- 255 length are expressed as decimal number of octets. Since there is no 256 predefined limit to the length of a payload, recipients ought to 257 anticipate potentially large decimal numerals and prevent parsing 258 errors due to integer conversion overflows. 260 2.2. Other Range Units 262 Range units are intended to be extensible. New range units ought to 263 be registered with IANA, as defined in Section 5.1. 265 other-range-unit = token 267 2.3. Accept-Ranges 269 The "Accept-Ranges" header field allows a server to indicate that it 270 supports range requests for the target resource. 272 Accept-Ranges = acceptable-ranges 273 acceptable-ranges = 1#range-unit / "none" 275 An origin server that supports byte-range requests for a given target 276 resource MAY send 278 Accept-Ranges: bytes 280 to indicate what range units are supported. A client MAY generate 281 range requests without having received this header field for the 282 resource involved. Range units are defined in Section 2. 284 A server that does not support any kind of range request for the 285 target resource resource MAY send 287 Accept-Ranges: none 289 to advise the client not to attempt a range request. 291 3. Range Requests 293 3.1. Range 295 The "Range" header field on a GET request modifies the method 296 semantics to request transfer of only one or more subranges of the 297 selected representation data, rather than the entire selected 298 representation data. 300 Range = byte-ranges-specifier / other-ranges-specifier 301 other-ranges-specifier = other-range-unit "=" other-range-set 302 other-range-set = 1*CHAR 304 A server MAY ignore the Range header field. However, origin servers 305 and intermediate caches ought to support byte ranges when possible, 306 since Range supports efficient recovery from partially failed 307 transfers and partial retrieval of large representations. A server 308 MUST ignore a Range header field received with a request method other 309 than GET. 311 An origin server MUST ignore a Range header field that contains a 312 range unit it does not understand. A proxy MAY discard a Range 313 header field that contains a range unit it does not understand. 315 A server that supports range requests MAY ignore or reject a Range 316 header field that consists of more than two overlapping ranges, or a 317 set of many small ranges that are not listed in ascending order, 318 since both are indications of either a broken client or a deliberate 319 denial of service attack (Section 6.1). A client SHOULD NOT request 320 multiple ranges that are inherently less efficient to process and 321 transfer than a single range that encompasses the same data. 323 A client that is requesting multiple ranges SHOULD list those ranges 324 in ascending order (the order in which they would typically be 325 received in a complete representation) unless there is a specific 326 need to request a later part earlier. For example, a user agent 327 processing a large representation with an internal catalog of parts 328 might need to request later parts first, particularly if the 329 representation consists of pages stored in reverse order and the user 330 agent wishes to transfer one page at a time. 332 The Range header field is evaluated after evaluating the precondition 333 header fields defined in [Part4], and only if the result in absence 334 of the Range header field would be a 200 (OK) response. In other 335 words, Range is ignored when a conditional GET would result in a 304 336 (Not Modified) response. 338 The If-Range header field (Section 3.2) can be used as a precondition 339 to applying the Range header field. 341 If all of the preconditions are true, the server supports the Range 342 header field for the target resource, and the specified range(s) are 343 valid and satisfiable (as defined in Section 2.1), the server SHOULD 344 send a 206 (Partial Content) response with a payload containing one 345 or more partial representations that correspond to the satisfiable 346 ranges requested, as defined in Section 4. 348 If all of the preconditions are true, the server supports the Range 349 header field for the target resource, and the specified range(s) are 350 invalid or unsatisfiable, the server SHOULD send a 416 (Range Not 351 Satisfiable) response. 353 3.2. If-Range 355 If a client has a partial copy of a representation and wishes to have 356 an up-to-date copy of the entire representation, it could use the 357 Range header field with a conditional GET (using either or both of 358 If-Unmodified-Since and If-Match.) However, if the precondition 359 fails because the representation has been modified, the client would 360 then have to make a second request to obtain the entire current 361 representation. 363 The "If-Range" header field allows a client to "short-circuit" the 364 second request. Informally, its meaning is: if the representation is 365 unchanged, send me the part(s) that I am requesting in Range; 366 otherwise, send me the entire representation. 368 If-Range = entity-tag / HTTP-date 370 A client MUST NOT generate an If-Range header field in a request that 371 does not contain a Range header field. A server MUST ignore an If- 372 Range header field received in a request that does not contain a 373 Range header field. An origin server MUST ignore an If-Range header 374 field received in a request for a target resource that does not 375 support Range requests. 377 A client MUST NOT generate an If-Range header field containing an 378 entity-tag that is marked as weak. A client MUST NOT generate an If- 379 Range header field containing an HTTP-date unless the client has no 380 entity-tag for the corresponding representation and the date is a 381 strong validator in the sense defined by Section 2.2.2 of [Part4]. 383 A server that evaluates an If-Range precondition MUST use the strong 384 comparison function when comparing entity-tags (Section 2.3.2 of 385 [Part4]) and MUST evaluate the condition as false if an HTTP-date 386 validator is provided that is not a strong validator in the sense 387 defined by Section 2.2.2 of [Part4]. (A server can distinguish 388 between a valid HTTP-date and any form of entity-tag by examining the 389 first two characters.) 391 If the validator given in the If-Range header field matches the 392 current validator for the selected representation of the target 393 resource, then the server SHOULD process the Range header field as 394 requested. If the validator does not match, the server MUST ignore 395 the Range header field. 397 4. Responses to a Range Request 398 4.1. 206 Partial Content 400 The 206 (Partial Content) status code indicates that the server is 401 successfully fulfilling a range request for the target resource by 402 transferring one or more parts of the selected representation that 403 correspond to the satisfiable ranges found in the request's Range 404 header field (Section 3.1). 406 If a single part is being transferred, the server generating the 206 407 response MUST generate a Content-Range header field, describing what 408 range of the selected representation is enclosed, and a payload 409 consisting of the range. For example: 411 HTTP/1.1 206 Partial Content 412 Date: Wed, 15 Nov 1995 06:25:24 GMT 413 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 414 Content-Range: bytes 21010-47021/47022 415 Content-Length: 26012 416 Content-Type: image/gif 418 ... 26012 bytes of partial image data ... 420 If multiple parts are being transferred, the server generating the 421 206 response MUST generate a "multipart/byteranges" payload, as 422 defined in Appendix A, and a Content-Type header field containing the 423 multipart/byteranges media type and its required boundary parameter. 424 To avoid confusion with single part responses, a server MUST NOT 425 generate a Content-Range header field in the HTTP header section of a 426 multiple part response (this field will be sent in each part 427 instead). 429 Within the header area of each body part in the multipart payload, 430 the server MUST generate a Content-Range header field corresponding 431 to the range being enclosed in that body part. If the selected 432 representation would have had a Content-Type header field in a 200 433 (OK) response, the server SHOULD generate that same Content-Type 434 field in the header area of each body part. For 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-Length: 1741 440 Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES 442 --THIS_STRING_SEPARATES 443 Content-Type: application/pdf 444 Content-Range: bytes 500-999/8000 446 ...the first range... 447 --THIS_STRING_SEPARATES 448 Content-Type: application/pdf 449 Content-Range: bytes 7000-7999/8000 451 ...the second range 452 --THIS_STRING_SEPARATES-- 454 When multiple ranges are requested, a server MAY coalesce any of the 455 ranges that overlap or that are separated by a gap that is smaller 456 than the overhead of sending multiple parts, regardless of the order 457 in which the corresponding byte-range-spec appeared in the received 458 Range header field. Since the typical overhead between parts of a 459 multipart/byteranges payload is around 80 bytes, depending on the 460 selected representation's media type and the chosen boundary 461 parameter length, it can be less efficient to transfer many small 462 disjoint parts than it is to transfer the entire selected 463 representation. 465 A server MUST NOT generate a multipart response to a request for a 466 single range, since a client that does not request multiple parts 467 might not support multipart responses. However, a server MAY 468 generate a multipart/byteranges payload with only a single body part 469 if multiple ranges were requested and only one range was found to be 470 satisfiable or only one range remained after coalescing. A client 471 that cannot process a multipart/byteranges response MUST NOT generate 472 a request that asks for multiple ranges. 474 When a multipart response payload is generated, the server SHOULD 475 send the parts in the same order that the corresponding byte-range- 476 spec appeared in the received Range header field, excluding those 477 ranges that were deemed unsatisfiable or that were coalesced into 478 other ranges. A client that receives a multipart response MUST 479 inspect the Content-Range header field present in each body part in 480 order to determine which range is contained in that body part; a 481 client cannot rely on receiving the same ranges that it requested, 482 nor the same order that it requested. 484 When a 206 response is generated, the server MUST generate the 485 following header fields, in addition to those required above, if the 486 field would have been sent in a 200 (OK) response to the same 487 request: Date, Cache-Control, ETag, Expires, Content-Location, and 488 Vary. 490 If a 206 is generated in response to a request with an If-Range 491 header field, the sender SHOULD NOT generate other representation 492 header fields beyond those required above, because the client is 493 understood to already have a prior response containing those header 494 fields. Otherwise, the sender MUST generate all of the 495 representation header fields that would have been sent in a 200 (OK) 496 response to the same request. 498 A 206 response is cacheable unless otherwise indicated by explicit 499 cache controls (see Section 4.2.2 of [Part6]). 501 4.2. Content-Range 503 The "Content-Range" header field is sent in a single part 206 504 (Partial Content) response to indicate the partial range of the 505 selected representation enclosed as the message payload, sent in each 506 part of a multipart 206 response to indicate the range enclosed 507 within each body part, and sent in 416 (Range Not Satisfiable) 508 responses to provide information about the selected representation. 510 Content-Range = byte-content-range 511 / other-content-range 513 byte-content-range = bytes-unit SP 514 ( byte-range-resp / unsatisfied-range ) 516 byte-range-resp = byte-range "/" ( complete-length / "*" ) 517 byte-range = first-byte-pos "-" last-byte-pos 518 unsatisfied-range = "*/" complete-length 520 complete-length = 1*DIGIT 522 other-content-range = other-range-unit SP other-range-resp 523 other-range-resp = *CHAR 525 If a 206 (Partial Content) response contains a Content-Range header 526 field with a range unit (Section 2) that the recipient does not 527 understand, the recipient MUST NOT attempt to recombine it with a 528 stored representation. A proxy that receives such a message SHOULD 529 forward it downstream. 531 For byte ranges, a sender SHOULD indicate the complete length of the 532 representation from which the range has been extracted, unless the 533 complete length is unknown or difficult to determine. An asterisk 534 character ("*") in place of the complete-length indicates that the 535 representation length was unknown when the header field was 536 generated. 538 The following example illustrates when the complete length of the 539 selected representation is known by the sender to be 1234 bytes: 541 Content-Range: bytes 42-1233/1234 543 and this second example illustrates when the complete length is 544 unknown: 546 Content-Range: bytes 42-1233/* 548 A Content-Range field value is invalid if it contains a byte-range- 549 resp that has a last-byte-pos value less than its first-byte-pos 550 value, or a complete-length value less than or equal to its last- 551 byte-pos value. The recipient of an invalid Content-Range MUST NOT 552 attempt to recombine the received content with a stored 553 representation. 555 A server generating a 416 (Range Not Satisfiable) response to a byte 556 range request SHOULD send a Content-Range header field with an 557 unsatisfied-range value, as in the following example: 559 Content-Range: bytes */1234 561 The complete-length in a 416 response indicates the current length of 562 the selected representation. 564 The "Content-Range" header field has no meaning for status codes that 565 do not explicitly describe its semantic. For this specification, 566 only the 206 (Partial Content) and 416 (Range Not Satisfiable) status 567 codes describe a meaning for Content-Range. 569 The following are examples of Content-Range values in which the 570 selected representation contains a total of 1234 bytes: 572 o The first 500 bytes: 574 Content-Range: bytes 0-499/1234 576 o The second 500 bytes: 578 Content-Range: bytes 500-999/1234 580 o All except for the first 500 bytes: 582 Content-Range: bytes 500-1233/1234 584 o The last 500 bytes: 586 Content-Range: bytes 734-1233/1234 588 4.3. Combining Ranges 590 A response might transfer only a subrange of a representation if the 591 connection closed prematurely or if the request used one or more 592 Range specifications. After several such transfers, a client might 593 have received several ranges of the same representation. These 594 ranges can only be safely combined if they all have in common the 595 same strong validator (Section 2.1 of [Part4]). 597 A client that has received multiple partial responses to GET requests 598 on a target resource MAY combine those responses into a larger 599 continuous range if they share the same strong validator. 601 If the most recent response is an incomplete 200 (OK) response, then 602 the header fields of that response are used for any combined response 603 and replace those of the matching stored responses. 605 If the most recent response is a 206 (Partial Content) response and 606 at least one of the matching stored responses is a 200 (OK), then the 607 combined response header fields consist of the most recent 200 608 response's header fields. If all of the matching stored responses 609 are 206 responses, then the stored response with the most recent 610 header fields is used as the source of header fields for the combined 611 response, except that the client MUST use other header fields 612 provided in the new response, aside from Content-Range, to replace 613 all instances of the corresponding header fields in the stored 614 response. 616 The combined response message body consists of the union of partial 617 content ranges in the new response and each of the selected 618 responses. If the union consists of the entire range of the 619 representation, then the client MUST process the combined response as 620 if it were a complete 200 (OK) response, including a Content-Length 621 header field that reflects the complete length. Otherwise, the 622 client MUST process the set of continuous ranges as one of the 623 following: an incomplete 200 (OK) response if the combined response 624 is a prefix of the representation, a single 206 (Partial Content) 625 response containing a multipart/byteranges body, or multiple 206 626 (Partial Content) responses, each with one continuous range that is 627 indicated by a Content-Range header field. 629 4.4. 416 Range Not Satisfiable 631 The 416 (Range Not Satisfiable) status code indicates that none of 632 the ranges in the request's Range header field (Section 3.1) overlap 633 the current extent of the selected resource or that the set of ranges 634 requested has been rejected due to invalid ranges or an excessive 635 request of small or overlapping ranges. 637 For byte ranges, failing to overlap the current extent means that the 638 first-byte-pos of all of the byte-range-spec values were greater than 639 the current length of the selected representation. When this status 640 code is generated in response to a byte range request, the sender 641 SHOULD generate a Content-Range header field specifying the current 642 length of the selected representation (Section 4.2). 644 For example: 646 HTTP/1.1 416 Range Not Satisfiable 647 Date: Fri, 20 Jan 2012 15:41:54 GMT 648 Content-Range: bytes */47022 650 Note: Because servers are free to ignore Range, many 651 implementations will simply respond with the entire selected 652 representation in a 200 (OK) response. That is partly because 653 most clients are prepared to receive a 200 (OK) to complete the 654 task (albeit less efficiently) and partly because clients might 655 not stop making an invalid partial request until they have 656 received a complete representation. Thus, clients cannot depend 657 on receiving a 416 (Range Not Satisfiable) response even when it 658 is most appropriate. 660 5. IANA Considerations 662 5.1. Range Unit Registry 664 The HTTP Range Unit Registry defines the name space for the range 665 unit names and refers to their corresponding specifications. The 666 registry will be created and maintained at 667 . 669 5.1.1. Procedure 671 Registration of an HTTP Range Unit MUST include the following fields: 673 o Name 675 o Description 676 o Pointer to specification text 678 Values to be added to this name space require IETF Review (see 679 [RFC5226], Section 4.1). 681 5.1.2. Registrations 683 The initial HTTP Range Unit Registry shall contain the registrations 684 below: 686 +-------------+---------------------------------------+-------------+ 687 | Range Unit | Description | Reference | 688 | Name | | | 689 +-------------+---------------------------------------+-------------+ 690 | bytes | a range of octets | Section 2.1 | 691 | none | reserved as keyword, indicating no | Section 2.3 | 692 | | ranges are supported | | 693 +-------------+---------------------------------------+-------------+ 695 The change controller is: "IETF (iesg@ietf.org) - Internet 696 Engineering Task Force". 698 5.2. Status Code Registration 700 The HTTP Status Code Registry located at 701 shall be updated 702 with the registrations below: 704 +-------+-----------------------+-------------+ 705 | Value | Description | Reference | 706 +-------+-----------------------+-------------+ 707 | 206 | Partial Content | Section 4.1 | 708 | 416 | Range Not Satisfiable | Section 4.4 | 709 +-------+-----------------------+-------------+ 711 5.3. Header Field Registration 713 HTTP header fields are registered within the Message Header Field 714 Registry maintained at . 717 This document defines the following HTTP header fields, so their 718 associated registry entries shall be updated according to the 719 permanent registrations below (see [BCP90]): 721 +-------------------+----------+----------+-------------+ 722 | Header Field Name | Protocol | Status | Reference | 723 +-------------------+----------+----------+-------------+ 724 | Accept-Ranges | http | standard | Section 2.3 | 725 | Content-Range | http | standard | Section 4.2 | 726 | If-Range | http | standard | Section 3.2 | 727 | Range | http | standard | Section 3.1 | 728 +-------------------+----------+----------+-------------+ 730 The change controller is: "IETF (iesg@ietf.org) - Internet 731 Engineering Task Force". 733 6. Security Considerations 735 This section is meant to inform developers, information providers, 736 and users of known security concerns specific to the HTTP/1.1 range 737 request mechanisms. More general security considerations are 738 addressed in HTTP messaging [Part1] and semantics [Part2]. 740 6.1. Denial of Service Attacks using Range 742 Unconstrained multiple range requests are susceptible to denial of 743 service attacks because the effort required to request many 744 overlapping ranges of the same data is tiny compared to the time, 745 memory, and bandwidth consumed by attempting to serve the requested 746 data in many parts. Servers ought to ignore, coalesce, or reject 747 egregious range requests, such as requests for more than two 748 overlapping ranges or for many small ranges in a single set, 749 particularly when the ranges are requested out of order for no 750 apparent reason. Multipart range requests are not designed to 751 support random access. 753 7. Acknowledgments 755 See Section 10 of [Part1]. 757 8. References 759 8.1. Normative References 761 [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 762 Protocol (HTTP/1.1): Message Syntax and Routing", 763 draft-ietf-httpbis-p1-messaging-24 (work in progress), 764 September 2013. 766 [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 767 Protocol (HTTP/1.1): Semantics and Content", 768 draft-ietf-httpbis-p2-semantics-24 (work in progress), 769 September 2013. 771 [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 772 Protocol (HTTP/1.1): Conditional Requests", 773 draft-ietf-httpbis-p4-conditional-24 (work in progress), 774 September 2013. 776 [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 777 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 778 draft-ietf-httpbis-p6-cache-24 (work in progress), 779 September 2013. 781 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 782 Extensions (MIME) Part Two: Media Types", RFC 2046, 783 November 1996. 785 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 786 Requirement Levels", BCP 14, RFC 2119, March 1997. 788 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 789 Specifications: ABNF", STD 68, RFC 5234, January 2008. 791 8.2. Informative References 793 [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type 794 Specifications and Registration Procedures", BCP 13, 795 RFC 6838, January 2013. 797 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration 798 Procedures for Message Header Fields", BCP 90, RFC 3864, 799 September 2004. 801 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 802 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 803 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 805 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 806 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 807 May 2008. 809 Appendix A. Internet Media Type multipart/byteranges 811 When a 206 (Partial Content) response message includes the content of 812 multiple ranges, they are transmitted as body parts in a multipart 813 message body ([RFC2046], Section 5.1) with the media type of 814 "multipart/byteranges". The following definition is to be registered 815 with IANA [BCP13]. 817 The multipart/byteranges media type includes one or more body parts, 818 each with its own Content-Type and Content-Range fields. The 819 required boundary parameter specifies the boundary string used to 820 separate each body part. 822 Type name: multipart 824 Subtype name: byteranges 826 Required parameters: boundary 828 Optional parameters: none 830 Encoding considerations: only "7bit", "8bit", or "binary" are 831 permitted 833 Security considerations: none 835 Interoperability considerations: none 837 Published specification: This specification (see Appendix A). 839 Applications that use this media type: HTTP components supporting 840 multiple ranges in a single request. 842 Additional information: 844 Magic number(s): none 846 File extension(s): none 848 Macintosh file type code(s): none 850 Person and email address to contact for further information: See 851 Authors Section. 853 Intended usage: COMMON 855 Restrictions on usage: none 857 Author: See Authors Section. 859 Change controller: IESG 861 Implementation Notes: 863 1. Additional CRLFs might precede the first boundary string in the 864 body. 866 2. Although [RFC2046] permits the boundary string to be quoted, some 867 existing implementations handle a quoted boundary string 868 incorrectly. 870 3. A number of clients and servers were coded to an early draft of 871 the byteranges specification that used a media type of multipart/ 872 x-byteranges, which is almost (but not quite) compatible with 873 this type. 875 Despite the name, the "multipart/byteranges" media type is not 876 limited to byte ranges. The following example uses an "exampleunit" 877 range unit: 879 HTTP/1.1 206 Partial Content 880 Date: Tue, 14 Nov 1995 06:25:24 GMT 881 Last-Modified: Tue, 14 July 04:58:08 GMT 882 Content-Length: 2331785 883 Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES 885 --THIS_STRING_SEPARATES 886 Content-Type: video/example 887 Content-Range: exampleunit 1.2-4.3/25 889 ...the first range... 890 --THIS_STRING_SEPARATES 891 Content-Type: video/example 892 Content-Range: exampleunit 11.2-14.3/25 894 ...the second range 895 --THIS_STRING_SEPARATES-- 897 Appendix B. Changes from RFC 2616 899 Servers are given more leeway in how they respond to a range request, 900 in order to mitigate abuse by malicious (or just greedy) clients. 901 (Section 3.1) 903 A weak validator cannot be used in a 206 response. (Section 4.1) 905 The Content-Range header field only has meaning when the status code 906 explicitly defines its use. (Section 4.2) 908 This specification introduces a Range Unit Registry. (Section 5.1) 910 multipart/byteranges can consist of a single part. (Appendix A) 912 Appendix C. Imported ABNF 914 The following core rules are included by reference, as defined in 915 Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), 916 CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double 917 quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 918 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII 919 character). 921 Note that all rules derived from token are to be compared case- 922 insensitively, like range-unit and acceptable-ranges. 924 The rules below are defined in [Part1]: 926 OWS = 927 token = 929 The rules below are defined in other parts: 931 HTTP-date = 932 entity-tag = 934 Appendix D. Collected ABNF 936 In the collected ABNF below, list rules are expanded as per Section 937 1.2 of [Part1]. 939 Accept-Ranges = acceptable-ranges 941 Content-Range = byte-content-range / other-content-range 943 HTTP-date = 945 If-Range = entity-tag / HTTP-date 947 OWS = 949 Range = byte-ranges-specifier / other-ranges-specifier 951 acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS 952 range-unit ] ) ) / "none" 954 byte-content-range = bytes-unit SP ( byte-range-resp / 955 unsatisfied-range ) 956 byte-range = first-byte-pos "-" last-byte-pos 957 byte-range-resp = byte-range "/" ( complete-length / "*" ) 958 byte-range-set = *( "," OWS ) ( byte-range-spec / 959 suffix-byte-range-spec ) *( OWS "," [ OWS ( byte-range-spec / 960 suffix-byte-range-spec ) ] ) 961 byte-range-spec = first-byte-pos "-" [ last-byte-pos ] 962 byte-ranges-specifier = bytes-unit "=" byte-range-set 963 bytes-unit = "bytes" 965 complete-length = 1*DIGIT 967 entity-tag = 969 first-byte-pos = 1*DIGIT 971 last-byte-pos = 1*DIGIT 973 other-content-range = other-range-unit SP other-range-resp 974 other-range-resp = *CHAR 975 other-range-set = 1*CHAR 976 other-range-unit = token 977 other-ranges-specifier = other-range-unit "=" other-range-set 979 range-unit = bytes-unit / other-range-unit 981 suffix-byte-range-spec = "-" suffix-length 982 suffix-length = 1*DIGIT 984 token = 986 unsatisfied-range = "*/" complete-length 988 Appendix E. Change Log (to be removed by RFC Editor before publication) 990 Changes up to the first Working Group Last Call draft are summarized 991 in . 994 E.1. Since draft-ietf-httpbis-p5-range-19 996 Closed issues: 998 o : "ABNF list 999 expansion code problem" 1001 o : "ABNF 1002 requirements for recipients" 1004 o : "reserve 1005 'none' as byte range unit" 1007 o : "note 1008 introduction of new IANA registries as normative changes" 1010 o : "range units 1011 vs leading zeroes vs size" 1013 E.2. Since draft-ietf-httpbis-p5-range-20 1015 o Conformance criteria and considerations regarding error handling 1016 are now defined in Part 1. 1018 E.3. Since draft-ietf-httpbis-p5-range-21 1020 Closed issues: 1022 o : "Security 1023 consideration: range flooding" 1025 o : "Allowing 1026 heuristic caching for new status codes" 1028 o : "Add 1029 limitations to Range to reduce its use as a denial-of-service 1030 tool" 1032 o : "416 and 1033 multipart/byteranges" 1035 E.4. Since draft-ietf-httpbis-p5-range-22 1037 Closed issues: 1039 o : "explain list 1040 expansion in ABNF appendices" 1042 o : "incorrect 1043 example dates" 1045 o : "media type 1046 registration template issues" 1048 o : "Editorial 1049 suggestions" 1051 o : "MUSTs and 1052 other feedback" 1054 E.5. Since draft-ietf-httpbis-p5-range-23 1056 Closed issues: 1058 o : "is P5's 1059 definition of strong validator consistent with P4?" 1061 o : "p5 editorial 1062 comments" 1064 Index 1066 2 1067 206 Partial Content (status code) 10 1069 4 1070 416 Range Not Satisfiable (status code) 15 1072 A 1073 Accept-Ranges header field 7 1075 C 1076 Content-Range header field 12 1078 G 1079 Grammar 1080 Accept-Ranges 7 1081 acceptable-ranges 7 1082 byte-content-range 12 1083 byte-range 12 1084 byte-range-resp 12 1085 byte-range-set 5 1086 byte-range-spec 5 1087 byte-ranges-specifier 5 1088 bytes-unit 5 1089 complete-length 12 1090 Content-Range 12 1091 first-byte-pos 5 1092 If-Range 9 1093 last-byte-pos 5 1094 other-content-range 12 1095 other-range-resp 12 1096 other-range-unit 5, 7 1097 Range 7 1098 range-unit 5 1099 ranges-specifier 5 1100 suffix-byte-range-spec 6 1101 suffix-length 6 1102 unsatisfied-range 12 1104 I 1105 If-Range header field 9 1107 M 1108 Media Type 1109 multipart/byteranges 18 1110 multipart/x-byteranges 20 1111 multipart/byteranges Media Type 18 1112 multipart/x-byteranges Media Type 20 1114 R 1115 Range header field 7 1117 Authors' Addresses 1119 Roy T. Fielding (editor) 1120 Adobe Systems Incorporated 1121 345 Park Ave 1122 San Jose, CA 95110 1123 USA 1125 EMail: fielding@gbiv.com 1126 URI: http://roy.gbiv.com/ 1127 Yves Lafon (editor) 1128 World Wide Web Consortium 1129 W3C / ERCIM 1130 2004, rte des Lucioles 1131 Sophia-Antipolis, AM 06902 1132 France 1134 EMail: ylafon@w3.org 1135 URI: http://www.raubacapeu.net/people/yves/ 1137 Julian F. Reschke (editor) 1138 greenbytes GmbH 1139 Hafenweg 16 1140 Muenster, NW 48155 1141 Germany 1143 EMail: julian.reschke@greenbytes.de 1144 URI: http://greenbytes.de/tech/webdav/