idnits 2.17.1 draft-ietf-httpbis-p5-range-26.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 (February 6, 2014) is 3724 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 858, but no explicit reference was found in the text -- 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 (~~), 2 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: August 10, 2014 J. Reschke, Ed. 7 greenbytes 8 February 6, 2014 10 Hypertext Transfer Protocol (HTTP/1.1): Range Requests 11 draft-ietf-httpbis-p5-range-26 13 Abstract 15 The Hypertext Transfer Protocol (HTTP) is a stateless application- 16 level 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.2. 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 August 10, 2014. 50 Copyright Notice 52 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . 10 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 5.4. Internet Media Type Registration . . . . . . . . . . . . . 17 101 5.4.1. Internet Media Type multipart/byteranges . . . . . . . 17 102 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 103 6.1. Denial of Service Attacks using Range . . . . . . . . . . 18 104 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 105 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 106 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 107 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 108 Appendix A. Internet Media Type multipart/byteranges . . . . . . 20 109 Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 21 110 Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 21 111 Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 21 112 Appendix E. Change Log (to be removed by RFC Editor before 113 publication) . . . . . . . . . . . . . . . . . . . . 23 114 E.1. Since draft-ietf-httpbis-p5-range-24 . . . . . . . . . . . 23 115 E.2. Since draft-ietf-httpbis-p5-range-25 . . . . . . . . . . . 23 116 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 118 1. Introduction 120 Hypertext Transfer Protocol (HTTP) clients often encounter 121 interrupted data transfers as a result of canceled requests or 122 dropped connections. When a client has stored a partial 123 representation, it is desirable to request the remainder of that 124 representation in a subsequent request rather than transfer the 125 entire representation. Likewise, devices with limited local storage 126 might benefit from being able to request only a subset of a larger 127 representation, such as a single page of a very large document, or 128 the dimensions of an embedded image. 130 This document defines HTTP/1.1 range requests, partial responses, and 131 the multipart/byteranges media type. Range requests are an OPTIONAL 132 feature of HTTP, designed so that recipients not implementing this 133 feature (or not supporting it for the target resource) can respond as 134 if it is a normal GET request without impacting interoperability. 135 Partial responses are indicated by a distinct status code to not be 136 mistaken for full responses by caches that might not implement the 137 feature. 139 Although the range request mechanism is designed to allow for 140 extensible range types, this specification only defines requests for 141 byte ranges. 143 1.1. Conformance and Error Handling 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 Conformance criteria and considerations regarding error handling are 150 defined in Section 2.5 of [Part1]. 152 1.2. Syntax Notation 154 This specification uses the Augmented Backus-Naur Form (ABNF) 155 notation of [RFC5234] with a list extension, defined in Section 7 of 156 [Part1], that allows for compact definition of comma-separated lists 157 using a '#' operator (similar to how the '*' operator indicates 158 repetition). Appendix C describes rules imported from other 159 documents. Appendix D shows the collected grammar with all list 160 operators expanded to standard ABNF notation. 162 2. Range Units 164 A representation can be partitioned into subranges according to 165 various structural units, depending on the structure inherent in the 166 representation's media type. This "range unit" is used in the 167 Accept-Ranges (Section 2.3) response header field to advertise 168 support for range requests, the Range (Section 3.1) request header 169 field to delineate the parts of a representation that are requested, 170 and the Content-Range (Section 4.2) payload header field to describe 171 which part of a representation is being transferred. 173 range-unit = bytes-unit / other-range-unit 175 2.1. Byte Ranges 177 Since representation data is transferred in payloads as a sequence of 178 octets, a byte range is a meaningful substructure for any 179 representation transferable over HTTP (Section 3 of [Part2]). The 180 "bytes" range unit is defined for expressing subranges of the data's 181 octet sequence. 183 bytes-unit = "bytes" 185 A byte range request can specify a single range of bytes, or a set of 186 ranges within a single representation. 188 byte-ranges-specifier = bytes-unit "=" byte-range-set 189 byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec ) 190 byte-range-spec = first-byte-pos "-" [ last-byte-pos ] 191 first-byte-pos = 1*DIGIT 192 last-byte-pos = 1*DIGIT 194 The first-byte-pos value in a byte-range-spec gives the byte-offset 195 of the first byte in a range. The last-byte-pos value gives the 196 byte-offset of the last byte in the range; that is, the byte 197 positions specified are inclusive. Byte offsets start at zero. 199 Examples of byte-ranges-specifier values: 201 o The first 500 bytes (byte offsets 0-499, inclusive): 203 bytes=0-499 205 o The second 500 bytes (byte offsets 500-999, inclusive): 207 bytes=500-999 209 A byte-range-spec is invalid if the last-byte-pos value is present 210 and less than the first-byte-pos. 212 A client can limit the number of bytes requested without knowing the 213 size of the selected representation. If the last-byte-pos value is 214 absent, or if the value is greater than or equal to the current 215 length of the representation data, the byte range is interpreted as 216 the remainder of the representation (i.e., the server replaces the 217 value of last-byte-pos with a value that is one less than the current 218 length of the selected representation). 220 A client can request the last N bytes of the selected representation 221 using a suffix-byte-range-spec. 223 suffix-byte-range-spec = "-" suffix-length 224 suffix-length = 1*DIGIT 226 If the selected representation is shorter than the specified suffix- 227 length, the entire representation is used. 229 Additional examples, assuming a representation of length 10000: 231 o The final 500 bytes (byte offsets 9500-9999, inclusive): 233 bytes=-500 235 Or: 237 bytes=9500- 239 o The first and last bytes only (bytes 0 and 9999): 241 bytes=0-0,-1 243 o Other valid (but not canonical) specifications of the second 500 244 bytes (byte offsets 500-999, inclusive): 246 bytes=500-600,601-999 247 bytes=500-700,601-999 249 If a valid byte-range-set includes at least one byte-range-spec with 250 a first-byte-pos that is less than the current length of the 251 representation, or at least one suffix-byte-range-spec with a non- 252 zero suffix-length, then the byte-range-set is satisfiable. 253 Otherwise, the byte-range-set is unsatisfiable. 255 In the byte range syntax, first-byte-pos, last-byte-pos, and suffix- 256 length are expressed as decimal number of octets. Since there is no 257 predefined limit to the length of a payload, recipients MUST 258 anticipate potentially large decimal numerals and prevent parsing 259 errors due to integer conversion overflows. 261 2.2. Other Range Units 263 Range units are intended to be extensible. New range units ought to 264 be registered with IANA, as defined in Section 5.1. 266 other-range-unit = token 268 2.3. Accept-Ranges 270 The "Accept-Ranges" header field allows a server to indicate that it 271 supports range requests for the target resource. 273 Accept-Ranges = acceptable-ranges 274 acceptable-ranges = 1#range-unit / "none" 276 An origin server that supports byte-range requests for a given target 277 resource MAY send 279 Accept-Ranges: bytes 281 to indicate what range units are supported. A client MAY generate 282 range requests without having received this header field for the 283 resource involved. Range units are defined in Section 2. 285 A server that does not support any kind of range request for the 286 target resource MAY send 288 Accept-Ranges: none 290 to advise the client not to attempt a range request. 292 3. Range Requests 294 3.1. Range 296 The "Range" header field on a GET request modifies the method 297 semantics to request transfer of only one or more subranges of the 298 selected representation data, rather than the entire selected 299 representation data. 301 Range = byte-ranges-specifier / other-ranges-specifier 302 other-ranges-specifier = other-range-unit "=" other-range-set 303 other-range-set = 1*VCHAR 305 A server MAY ignore the Range header field. However, origin servers 306 and intermediate caches ought to support byte ranges when possible, 307 since Range supports efficient recovery from partially failed 308 transfers and partial retrieval of large representations. A server 309 MUST ignore a Range header field received with a request method other 310 than GET. 312 An origin server MUST ignore a Range header field that contains a 313 range unit it does not understand. A proxy MAY discard a Range 314 header field that contains a range unit it does not understand. 316 A server that supports range requests MAY ignore or reject a Range 317 header field that consists of more than two overlapping ranges, or a 318 set of many small ranges that are not listed in ascending order, 319 since both are indications of either a broken client or a deliberate 320 denial of service attack (Section 6.1). A client SHOULD NOT request 321 multiple ranges that are inherently less efficient to process and 322 transfer than a single range that encompasses the same data. 324 A client that is requesting multiple ranges SHOULD list those ranges 325 in ascending order (the order in which they would typically be 326 received in a complete representation) unless there is a specific 327 need to request a later part earlier. For example, a user agent 328 processing a large representation with an internal catalog of parts 329 might need to request later parts first, particularly if the 330 representation consists of pages stored in reverse order and the user 331 agent wishes to transfer one page at a time. 333 The Range header field is evaluated after evaluating the precondition 334 header fields defined in [Part4], and only if the result in absence 335 of the Range header field would be a 200 (OK) response. In other 336 words, Range is ignored when a conditional GET would result in a 304 337 (Not Modified) response. 339 The If-Range header field (Section 3.2) can be used as a precondition 340 to applying the Range header field. 342 If all of the preconditions are true, the server supports the Range 343 header field for the target resource, and the specified range(s) are 344 valid and satisfiable (as defined in Section 2.1), the server SHOULD 345 send a 206 (Partial Content) response with a payload containing one 346 or more partial representations that correspond to the satisfiable 347 ranges requested, as defined in Section 4. 349 If all of the preconditions are true, the server supports the Range 350 header field for the target resource, and the specified range(s) are 351 invalid or unsatisfiable, the server SHOULD send a 416 (Range Not 352 Satisfiable) response. 354 3.2. If-Range 356 If a client has a partial copy of a representation and wishes to have 357 an up-to-date copy of the entire representation, it could use the 358 Range header field with a conditional GET (using either or both of 359 If-Unmodified-Since and If-Match.) However, if the precondition 360 fails because the representation has been modified, the client would 361 then have to make a second request to obtain the entire current 362 representation. 364 The "If-Range" header field allows a client to "short-circuit" the 365 second request. Informally, its meaning is: if the representation is 366 unchanged, send me the part(s) that I am requesting in Range; 367 otherwise, send me the entire representation. 369 If-Range = entity-tag / HTTP-date 371 A client MUST NOT generate an If-Range header field in a request that 372 does not contain a Range header field. A server MUST ignore an If- 373 Range header field received in a request that does not contain a 374 Range header field. An origin server MUST ignore an If-Range header 375 field received in a request for a target resource that does not 376 support Range requests. 378 A client MUST NOT generate an If-Range header field containing an 379 entity-tag that is marked as weak. A client MUST NOT generate an If- 380 Range header field containing an HTTP-date unless the client has no 381 entity-tag for the corresponding representation and the date is a 382 strong validator in the sense defined by Section 2.2.2 of [Part4]. 384 A server that evaluates an If-Range precondition MUST use the strong 385 comparison function when comparing entity-tags (Section 2.3.2 of 386 [Part4]) and MUST evaluate the condition as false if an HTTP-date 387 validator is provided that is not a strong validator in the sense 388 defined by Section 2.2.2 of [Part4]. A valid entity-tag can be 389 distinguished from a valid HTTP-date by examining the first two 390 characters for a DQUOTE. 392 If the validator given in the If-Range header field matches the 393 current validator for the selected representation of the target 394 resource, then the server SHOULD process the Range header field as 395 requested. If the validator does not match, the server MUST ignore 396 the Range header field. Note that this comparison by exact match, 397 including when the validator is an HTTP-date, differs from the 398 "earlier than or equal to" comparison used when evaluating an If- 399 Unmodified-Since conditional. 401 4. Responses to a Range Request 403 4.1. 206 Partial Content 405 The 206 (Partial Content) status code indicates that the server is 406 successfully fulfilling a range request for the target resource by 407 transferring one or more parts of the selected representation that 408 correspond to the satisfiable ranges found in the request's Range 409 header field (Section 3.1). 411 If a single part is being transferred, the server generating the 206 412 response MUST generate a Content-Range header field, describing what 413 range of the selected representation is enclosed, and a payload 414 consisting of the range. For example: 416 HTTP/1.1 206 Partial Content 417 Date: Wed, 15 Nov 1995 06:25:24 GMT 418 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 419 Content-Range: bytes 21010-47021/47022 420 Content-Length: 26012 421 Content-Type: image/gif 423 ... 26012 bytes of partial image data ... 425 If multiple parts are being transferred, the server generating the 426 206 response MUST generate a "multipart/byteranges" payload, as 427 defined in Appendix A, and a Content-Type header field containing the 428 multipart/byteranges media type and its required boundary parameter. 429 To avoid confusion with single part responses, a server MUST NOT 430 generate a Content-Range header field in the HTTP header section of a 431 multiple part response (this field will be sent in each part 432 instead). 434 Within the header area of each body part in the multipart payload, 435 the server MUST generate a Content-Range header field corresponding 436 to the range being enclosed in that body part. If the selected 437 representation would have had a Content-Type header field in a 200 438 (OK) response, the server SHOULD generate that same Content-Type 439 field in the header area of each body part. For example: 441 HTTP/1.1 206 Partial Content 442 Date: Wed, 15 Nov 1995 06:25:24 GMT 443 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 444 Content-Length: 1741 445 Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES 447 --THIS_STRING_SEPARATES 448 Content-Type: application/pdf 449 Content-Range: bytes 500-999/8000 451 ...the first range... 452 --THIS_STRING_SEPARATES 453 Content-Type: application/pdf 454 Content-Range: bytes 7000-7999/8000 456 ...the second range 457 --THIS_STRING_SEPARATES-- 459 When multiple ranges are requested, a server MAY coalesce any of the 460 ranges that overlap, or that are separated by a gap that is smaller 461 than the overhead of sending multiple parts, regardless of the order 462 in which the corresponding byte-range-spec appeared in the received 463 Range header field. Since the typical overhead between parts of a 464 multipart/byteranges payload is around 80 bytes, depending on the 465 selected representation's media type and the chosen boundary 466 parameter length, it can be less efficient to transfer many small 467 disjoint parts than it is to transfer the entire selected 468 representation. 470 A server MUST NOT generate a multipart response to a request for a 471 single range, since a client that does not request multiple parts 472 might not support multipart responses. However, a server MAY 473 generate a multipart/byteranges payload with only a single body part 474 if multiple ranges were requested and only one range was found to be 475 satisfiable or only one range remained after coalescing. A client 476 that cannot process a multipart/byteranges response MUST NOT generate 477 a request that asks for multiple ranges. 479 When a multipart response payload is generated, the server SHOULD 480 send the parts in the same order that the corresponding byte-range- 481 spec appeared in the received Range header field, excluding those 482 ranges that were deemed unsatisfiable or that were coalesced into 483 other ranges. A client that receives a multipart response MUST 484 inspect the Content-Range header field present in each body part in 485 order to determine which range is contained in that body part; a 486 client cannot rely on receiving the same ranges that it requested, 487 nor the same order that it requested. 489 When a 206 response is generated, the server MUST generate the 490 following header fields, in addition to those required above, if the 491 field would have been sent in a 200 (OK) response to the same 492 request: Date, Cache-Control, ETag, Expires, Content-Location, and 493 Vary. 495 If a 206 is generated in response to a request with an If-Range 496 header field, the sender SHOULD NOT generate other representation 497 header fields beyond those required above, because the client is 498 understood to already have a prior response containing those header 499 fields. Otherwise, the sender MUST generate all of the 500 representation header fields that would have been sent in a 200 (OK) 501 response to the same request. 503 A 206 response is cacheable by default; i.e., unless otherwise 504 indicated by explicit cache controls (see Section 4.2.2 of [Part6]). 506 4.2. Content-Range 508 The "Content-Range" header field is sent in a single part 206 509 (Partial Content) response to indicate the partial range of the 510 selected representation enclosed as the message payload, sent in each 511 part of a multipart 206 response to indicate the range enclosed 512 within each body part, and sent in 416 (Range Not Satisfiable) 513 responses to provide information about the selected representation. 515 Content-Range = byte-content-range 516 / other-content-range 518 byte-content-range = bytes-unit SP 519 ( byte-range-resp / unsatisfied-range ) 521 byte-range-resp = byte-range "/" ( complete-length / "*" ) 522 byte-range = first-byte-pos "-" last-byte-pos 523 unsatisfied-range = "*/" complete-length 525 complete-length = 1*DIGIT 527 other-content-range = other-range-unit SP other-range-resp 528 other-range-resp = *CHAR 530 If a 206 (Partial Content) response contains a Content-Range header 531 field with a range unit (Section 2) that the recipient does not 532 understand, the recipient MUST NOT attempt to recombine it with a 533 stored representation. A proxy that receives such a message SHOULD 534 forward it downstream. 536 For byte ranges, a sender SHOULD indicate the complete length of the 537 representation from which the range has been extracted, unless the 538 complete length is unknown or difficult to determine. An asterisk 539 character ("*") in place of the complete-length indicates that the 540 representation length was unknown when the header field was 541 generated. 543 The following example illustrates when the complete length of the 544 selected representation is known by the sender to be 1234 bytes: 546 Content-Range: bytes 42-1233/1234 548 and this second example illustrates when the complete length is 549 unknown: 551 Content-Range: bytes 42-1233/* 553 A Content-Range field value is invalid if it contains a byte-range- 554 resp that has a last-byte-pos value less than its first-byte-pos 555 value, or a complete-length value less than or equal to its last- 556 byte-pos value. The recipient of an invalid Content-Range MUST NOT 557 attempt to recombine the received content with a stored 558 representation. 560 A server generating a 416 (Range Not Satisfiable) response to a byte 561 range request SHOULD send a Content-Range header field with an 562 unsatisfied-range value, as in the following example: 564 Content-Range: bytes */1234 566 The complete-length in a 416 response indicates the current length of 567 the selected representation. 569 The "Content-Range" header field has no meaning for status codes that 570 do not explicitly describe its semantic. For this specification, 571 only the 206 (Partial Content) and 416 (Range Not Satisfiable) status 572 codes describe a meaning for Content-Range. 574 The following are examples of Content-Range values in which the 575 selected representation contains a total of 1234 bytes: 577 o The first 500 bytes: 579 Content-Range: bytes 0-499/1234 581 o The second 500 bytes: 583 Content-Range: bytes 500-999/1234 585 o All except for the first 500 bytes: 587 Content-Range: bytes 500-1233/1234 589 o The last 500 bytes: 591 Content-Range: bytes 734-1233/1234 593 4.3. Combining Ranges 595 A response might transfer only a subrange of a representation if the 596 connection closed prematurely or if the request used one or more 597 Range specifications. After several such transfers, a client might 598 have received several ranges of the same representation. These 599 ranges can only be safely combined if they all have in common the 600 same strong validator (Section 2.1 of [Part4]). 602 A client that has received multiple partial responses to GET requests 603 on a target resource MAY combine those responses into a larger 604 continuous range if they share the same strong validator. 606 If the most recent response is an incomplete 200 (OK) response, then 607 the header fields of that response are used for any combined response 608 and replace those of the matching stored responses. 610 If the most recent response is a 206 (Partial Content) response and 611 at least one of the matching stored responses is a 200 (OK), then the 612 combined response header fields consist of the most recent 200 613 response's header fields. If all of the matching stored responses 614 are 206 responses, then the stored response with the most recent 615 header fields is used as the source of header fields for the combined 616 response, except that the client MUST use other header fields 617 provided in the new response, aside from Content-Range, to replace 618 all instances of the corresponding header fields in the stored 619 response. 621 The combined response message body consists of the union of partial 622 content ranges in the new response and each of the selected 623 responses. If the union consists of the entire range of the 624 representation, then the client MUST process the combined response as 625 if it were a complete 200 (OK) response, including a Content-Length 626 header field that reflects the complete length. Otherwise, the 627 client MUST process the set of continuous ranges as one of the 628 following: an incomplete 200 (OK) response if the combined response 629 is a prefix of the representation, a single 206 (Partial Content) 630 response containing a multipart/byteranges body, or multiple 206 631 (Partial Content) responses, each with one continuous range that is 632 indicated by a Content-Range header field. 634 4.4. 416 Range Not Satisfiable 636 The 416 (Range Not Satisfiable) status code indicates that none of 637 the ranges in the request's Range header field (Section 3.1) overlap 638 the current extent of the selected resource or that the set of ranges 639 requested has been rejected due to invalid ranges or an excessive 640 request of small or overlapping ranges. 642 For byte ranges, failing to overlap the current extent means that the 643 first-byte-pos of all of the byte-range-spec values were greater than 644 the current length of the selected representation. When this status 645 code is generated in response to a byte range request, the sender 646 SHOULD generate a Content-Range header field specifying the current 647 length of the selected representation (Section 4.2). 649 For example: 651 HTTP/1.1 416 Range Not Satisfiable 652 Date: Fri, 20 Jan 2012 15:41:54 GMT 653 Content-Range: bytes */47022 655 Note: Because servers are free to ignore Range, many 656 implementations will simply respond with the entire selected 657 representation in a 200 (OK) response. That is partly because 658 most clients are prepared to receive a 200 (OK) to complete the 659 task (albeit less efficiently) and partly because clients might 660 not stop making an invalid partial request until they have 661 received a complete representation. Thus, clients cannot depend 662 on receiving a 416 (Range Not Satisfiable) response even when it 663 is most appropriate. 665 5. IANA Considerations 667 5.1. Range Unit Registry 669 The HTTP Range Unit Registry defines the name space for the range 670 unit names and refers to their corresponding specifications. The 671 registry will be created and maintained at (the suggested URI) 672 . 674 5.1.1. Procedure 676 Registration of an HTTP Range Unit MUST include the following fields: 678 o Name 680 o Description 681 o Pointer to specification text 683 Values to be added to this name space require IETF Review (see 684 [RFC5226], Section 4.1). 686 5.1.2. Registrations 688 The initial HTTP Range Unit Registry shall contain the registrations 689 below: 691 +-------------+---------------------------------------+-------------+ 692 | Range Unit | Description | Reference | 693 | Name | | | 694 +-------------+---------------------------------------+-------------+ 695 | bytes | a range of octets | Section 2.1 | 696 | none | reserved as keyword, indicating no | Section 2.3 | 697 | | ranges are supported | | 698 +-------------+---------------------------------------+-------------+ 700 The change controller is: "IETF (iesg@ietf.org) - Internet 701 Engineering Task Force". 703 5.2. Status Code Registration 705 The HTTP Status Code Registry located at 706 shall be updated 707 with the registrations below: 709 +-------+-----------------------+-------------+ 710 | Value | Description | Reference | 711 +-------+-----------------------+-------------+ 712 | 206 | Partial Content | Section 4.1 | 713 | 416 | Range Not Satisfiable | Section 4.4 | 714 +-------+-----------------------+-------------+ 716 5.3. Header Field Registration 718 HTTP header fields are registered within the Message Header Field 719 Registry maintained at . 722 This document defines the following HTTP header fields, so their 723 associated registry entries shall be updated according to the 724 permanent registrations below (see [BCP90]): 726 +-------------------+----------+----------+-------------+ 727 | Header Field Name | Protocol | Status | Reference | 728 +-------------------+----------+----------+-------------+ 729 | Accept-Ranges | http | standard | Section 2.3 | 730 | Content-Range | http | standard | Section 4.2 | 731 | If-Range | http | standard | Section 3.2 | 732 | Range | http | standard | Section 3.1 | 733 +-------------------+----------+----------+-------------+ 735 The change controller is: "IETF (iesg@ietf.org) - Internet 736 Engineering Task Force". 738 5.4. Internet Media Type Registration 740 IANA maintains the registry of Internet media types [BCP13] at 741 . 743 This document serves as the specification for the Internet media type 744 "multipart/byteranges". The following is to be registered with IANA. 746 5.4.1. Internet Media Type multipart/byteranges 748 Type name: multipart 750 Subtype name: byteranges 752 Required parameters: boundary 754 Optional parameters: N/A 756 Encoding considerations: only "7bit", "8bit", or "binary" are 757 permitted 759 Security considerations: see Section 6 761 Interoperability considerations: N/A 763 Published specification: This specification (see Appendix A). 765 Applications that use this media type: HTTP components supporting 766 multiple ranges in a single request. 768 Fragment identifier considerations: N/A 770 Additional information: 772 Deprecated alias names for this type: N/A 774 Magic number(s): N/A 776 File extension(s): N/A 778 Macintosh file type code(s): N/A 780 Person and email address to contact for further information: See 781 Authors Section. 783 Intended usage: COMMON 785 Restrictions on usage: N/A 787 Author: See Authors Section. 789 Change controller: IESG 791 6. Security Considerations 793 This section is meant to inform developers, information providers, 794 and users of known security concerns specific to the HTTP range 795 request mechanisms. More general security considerations are 796 addressed in HTTP messaging [Part1] and semantics [Part2]. 798 6.1. Denial of Service Attacks using Range 800 Unconstrained multiple range requests are susceptible to denial of 801 service attacks because the effort required to request many 802 overlapping ranges of the same data is tiny compared to the time, 803 memory, and bandwidth consumed by attempting to serve the requested 804 data in many parts. Servers ought to ignore, coalesce, or reject 805 egregious range requests, such as requests for more than two 806 overlapping ranges or for many small ranges in a single set, 807 particularly when the ranges are requested out of order for no 808 apparent reason. Multipart range requests are not designed to 809 support random access. 811 7. Acknowledgments 813 See Section 10 of [Part1]. 815 8. References 816 8.1. Normative References 818 [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 819 Protocol (HTTP/1.1): Message Syntax and Routing", 820 draft-ietf-httpbis-p1-messaging-26 (work in progress), 821 February 2014. 823 [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 824 Protocol (HTTP/1.1): Semantics and Content", 825 draft-ietf-httpbis-p2-semantics-26 (work in progress), 826 February 2014. 828 [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 829 Protocol (HTTP/1.1): Conditional Requests", 830 draft-ietf-httpbis-p4-conditional-26 (work in progress), 831 February 2014. 833 [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 834 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 835 draft-ietf-httpbis-p6-cache-26 (work in progress), 836 February 2014. 838 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 839 Extensions (MIME) Part Two: Media Types", RFC 2046, 840 November 1996. 842 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 843 Requirement Levels", BCP 14, RFC 2119, March 1997. 845 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 846 Specifications: ABNF", STD 68, RFC 5234, January 2008. 848 8.2. Informative References 850 [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type 851 Specifications and Registration Procedures", BCP 13, 852 RFC 6838, January 2013. 854 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration 855 Procedures for Message Header Fields", BCP 90, RFC 3864, 856 September 2004. 858 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 859 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 860 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 862 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 863 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 864 May 2008. 866 Appendix A. Internet Media Type multipart/byteranges 868 When a 206 (Partial Content) response message includes the content of 869 multiple ranges, they are transmitted as body parts in a multipart 870 message body ([RFC2046], Section 5.1) with the media type of 871 "multipart/byteranges". 873 The multipart/byteranges media type includes one or more body parts, 874 each with its own Content-Type and Content-Range fields. The 875 required boundary parameter specifies the boundary string used to 876 separate each body part. 878 Implementation Notes: 880 1. Additional CRLFs might precede the first boundary string in the 881 body. 883 2. Although [RFC2046] permits the boundary string to be quoted, some 884 existing implementations handle a quoted boundary string 885 incorrectly. 887 3. A number of clients and servers were coded to an early draft of 888 the byteranges specification that used a media type of multipart/ 889 x-byteranges, which is almost (but not quite) compatible with 890 this type. 892 Despite the name, the "multipart/byteranges" media type is not 893 limited to byte ranges. The following example uses an "exampleunit" 894 range unit: 896 HTTP/1.1 206 Partial Content 897 Date: Tue, 14 Nov 1995 06:25:24 GMT 898 Last-Modified: Tue, 14 July 04:58:08 GMT 899 Content-Length: 2331785 900 Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES 902 --THIS_STRING_SEPARATES 903 Content-Type: video/example 904 Content-Range: exampleunit 1.2-4.3/25 906 ...the first range... 907 --THIS_STRING_SEPARATES 908 Content-Type: video/example 909 Content-Range: exampleunit 11.2-14.3/25 911 ...the second range 912 --THIS_STRING_SEPARATES-- 914 Appendix B. Changes from RFC 2616 916 Servers are given more leeway in how they respond to a range request, 917 in order to mitigate abuse by malicious (or just greedy) clients. 918 (Section 3.1) 920 A weak validator cannot be used in a 206 response. (Section 4.1) 922 The Content-Range header field only has meaning when the status code 923 explicitly defines its use. (Section 4.2) 925 This specification introduces a Range Unit Registry. (Section 5.1) 927 multipart/byteranges can consist of a single part. (Appendix A) 929 Appendix C. Imported ABNF 931 The following core rules are included by reference, as defined in 932 Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), 933 CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double 934 quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 935 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII 936 character). 938 Note that all rules derived from token are to be compared case- 939 insensitively, like range-unit and acceptable-ranges. 941 The rules below are defined in [Part1]: 943 OWS = 944 token = 946 The rules below are defined in other parts: 948 HTTP-date = 949 entity-tag = 951 Appendix D. Collected ABNF 953 In the collected ABNF below, list rules are expanded as per Section 954 1.2 of [Part1]. 956 Accept-Ranges = acceptable-ranges 958 Content-Range = byte-content-range / other-content-range 960 HTTP-date = 962 If-Range = entity-tag / HTTP-date 964 OWS = 966 Range = byte-ranges-specifier / other-ranges-specifier 968 acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS 969 range-unit ] ) ) / "none" 971 byte-content-range = bytes-unit SP ( byte-range-resp / 972 unsatisfied-range ) 973 byte-range = first-byte-pos "-" last-byte-pos 974 byte-range-resp = byte-range "/" ( complete-length / "*" ) 975 byte-range-set = *( "," OWS ) ( byte-range-spec / 976 suffix-byte-range-spec ) *( OWS "," [ OWS ( byte-range-spec / 977 suffix-byte-range-spec ) ] ) 978 byte-range-spec = first-byte-pos "-" [ last-byte-pos ] 979 byte-ranges-specifier = bytes-unit "=" byte-range-set 980 bytes-unit = "bytes" 982 complete-length = 1*DIGIT 984 entity-tag = 986 first-byte-pos = 1*DIGIT 988 last-byte-pos = 1*DIGIT 990 other-content-range = other-range-unit SP other-range-resp 991 other-range-resp = *CHAR 992 other-range-set = 1*VCHAR 993 other-range-unit = token 994 other-ranges-specifier = other-range-unit "=" other-range-set 996 range-unit = bytes-unit / other-range-unit 998 suffix-byte-range-spec = "-" suffix-length 999 suffix-length = 1*DIGIT 1001 token = 1003 unsatisfied-range = "*/" complete-length 1005 Appendix E. Change Log (to be removed by RFC Editor before publication) 1007 Changes up to the IETF Last Call draft are summarized in . 1010 E.1. Since draft-ietf-httpbis-p5-range-24 1012 Closed issues: 1014 o : "APPSDIR 1015 review of draft-ietf-httpbis-p5-range-24" 1017 o : "integer value 1018 parsing" 1020 o : "broken 1021 sentence in description of 206" 1023 E.2. Since draft-ietf-httpbis-p5-range-25 1025 Closed issues: 1027 o : "check media 1028 type registration templates" 1030 o : "use of CHAR 1031 for other-range-set" 1033 o : "add 1034 'stateless' to Abstract" 1036 o : "improve 1037 introduction of list rule" 1039 o : "augment 1040 security considerations with pointers to current research" 1042 Index 1044 2 1045 206 Partial Content (status code) 10 1047 4 1048 416 Range Not Satisfiable (status code) 15 1050 A 1051 Accept-Ranges header field 7 1053 C 1054 Content-Range header field 12 1056 G 1057 Grammar 1058 Accept-Ranges 7 1059 acceptable-ranges 7 1060 byte-content-range 12 1061 byte-range 12 1062 byte-range-resp 12 1063 byte-range-set 5 1064 byte-range-spec 5 1065 byte-ranges-specifier 5 1066 bytes-unit 5 1067 complete-length 12 1068 Content-Range 12 1069 first-byte-pos 5 1070 If-Range 9 1071 last-byte-pos 5 1072 other-content-range 12 1073 other-range-resp 12 1074 other-range-unit 5, 7 1075 Range 7 1076 range-unit 5 1077 ranges-specifier 5 1078 suffix-byte-range-spec 6 1079 suffix-length 6 1080 unsatisfied-range 12 1082 I 1083 If-Range header field 9 1085 M 1086 Media Type 1087 multipart/byteranges 17, 20 1088 multipart/x-byteranges 20 1089 multipart/byteranges Media Type 17, 20 1090 multipart/x-byteranges Media Type 20 1092 R 1093 Range header field 7 1095 Authors' Addresses 1097 Roy T. Fielding (editor) 1098 Adobe Systems Incorporated 1099 345 Park Ave 1100 San Jose, CA 95110 1101 USA 1103 EMail: fielding@gbiv.com 1104 URI: http://roy.gbiv.com/ 1106 Yves Lafon (editor) 1107 World Wide Web Consortium 1108 W3C / ERCIM 1109 2004, rte des Lucioles 1110 Sophia-Antipolis, AM 06902 1111 France 1113 EMail: ylafon@w3.org 1114 URI: http://www.raubacapeu.net/people/yves/ 1116 Julian F. Reschke (editor) 1117 greenbytes GmbH 1118 Hafenweg 16 1119 Muenster, NW 48155 1120 Germany 1122 EMail: julian.reschke@greenbytes.de 1123 URI: http://greenbytes.de/tech/webdav/