idnits 2.17.1 draft-ietf-httpbis-p5-range-25.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 (November 17, 2013) is 3813 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 847, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-25 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-25 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-25 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-25 -- 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: May 21, 2014 J. Reschke, Ed. 7 greenbytes 8 November 17, 2013 10 Hypertext Transfer Protocol (HTTP/1.1): Range Requests 11 draft-ietf-httpbis-p5-range-25 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.1. 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 May 21, 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 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 18 106 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 107 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 108 Appendix A. Internet Media Type multipart/byteranges . . . . . . 19 109 Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 20 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 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 117 1. Introduction 119 Hypertext Transfer Protocol (HTTP) clients often encounter 120 interrupted data transfers as a result of canceled requests or 121 dropped connections. When a client has stored a partial 122 representation, it is desirable to request the remainder of that 123 representation in a subsequent request rather than transfer the 124 entire representation. Likewise, devices with limited local storage 125 might benefit from being able to request only a subset of a larger 126 representation, such as a single page of a very large document, or 127 the dimensions of an embedded image. 129 This document defines HTTP/1.1 range requests, partial responses, and 130 the multipart/byteranges media type. Range requests are an OPTIONAL 131 feature of HTTP, designed so that recipients not implementing this 132 feature (or not supporting it for the target resource) can respond as 133 if it is a normal GET request without impacting interoperability. 134 Partial responses are indicated by a distinct status code to not be 135 mistaken for full responses by caches that might not implement the 136 feature. 138 Although the range request mechanism is designed to allow for 139 extensible range types, this specification only defines requests for 140 byte ranges. 142 1.1. Conformance and Error Handling 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 Conformance criteria and considerations regarding error handling are 149 defined in Section 2.5 of [Part1]. 151 1.2. Syntax Notation 153 This specification uses the Augmented Backus-Naur Form (ABNF) 154 notation of [RFC5234] with the list rule extension defined in Section 155 7 of [Part1]. Appendix C describes rules imported from other 156 documents. Appendix D shows the collected ABNF with the list rule 157 expanded. 159 2. Range Units 161 A representation can be partitioned into subranges according to 162 various structural units, depending on the structure inherent in the 163 representation's media type. This "range unit" is used in the 164 Accept-Ranges (Section 2.3) response header field to advertise 165 support for range requests, the Range (Section 3.1) request header 166 field to delineate the parts of a representation that are requested, 167 and the Content-Range (Section 4.2) payload header field to describe 168 which part of a representation is being transferred. 170 range-unit = bytes-unit / other-range-unit 172 2.1. Byte Ranges 174 Since representation data is transferred in payloads as a sequence of 175 octets, a byte range is a meaningful substructure for any 176 representation transferable over HTTP (Section 3 of [Part2]). We 177 define the "bytes" range unit for expressing subranges of the data's 178 octet sequence. 180 bytes-unit = "bytes" 182 A byte range request can specify a single range of bytes, or a set of 183 ranges within a single representation. 185 byte-ranges-specifier = bytes-unit "=" byte-range-set 186 byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec ) 187 byte-range-spec = first-byte-pos "-" [ last-byte-pos ] 188 first-byte-pos = 1*DIGIT 189 last-byte-pos = 1*DIGIT 191 The first-byte-pos value in a byte-range-spec gives the byte-offset 192 of the first byte in a range. The last-byte-pos value gives the 193 byte-offset of the last byte in the range; that is, the byte 194 positions specified are inclusive. Byte offsets start at zero. 196 Examples of byte-ranges-specifier values: 198 o The first 500 bytes (byte offsets 0-499, inclusive): 200 bytes=0-499 202 o The second 500 bytes (byte offsets 500-999, inclusive): 204 bytes=500-999 206 A byte-range-spec is invalid if the last-byte-pos value is present 207 and less than the first-byte-pos. 209 A client can limit the number of bytes requested without knowing the 210 size of the selected representation. If the last-byte-pos value is 211 absent, or if the value is greater than or equal to the current 212 length of the representation data, the byte range is interpreted as 213 the remainder of the representation (i.e., the server replaces the 214 value of last-byte-pos with a value that is one less than the current 215 length of the selected representation). 217 A client can request the last N bytes of the selected representation 218 using a suffix-byte-range-spec. 220 suffix-byte-range-spec = "-" suffix-length 221 suffix-length = 1*DIGIT 223 If the selected representation is shorter than the specified suffix- 224 length, the entire representation is used. 226 Additional examples, assuming a representation of length 10000: 228 o The final 500 bytes (byte offsets 9500-9999, inclusive): 230 bytes=-500 232 Or: 234 bytes=9500- 236 o The first and last bytes only (bytes 0 and 9999): 238 bytes=0-0,-1 240 o Other valid (but not canonical) specifications of the second 500 241 bytes (byte offsets 500-999, inclusive): 243 bytes=500-600,601-999 244 bytes=500-700,601-999 246 If a valid byte-range-set includes at least one byte-range-spec with 247 a first-byte-pos that is less than the current length of the 248 representation, or at least one suffix-byte-range-spec with a non- 249 zero suffix-length, then the byte-range-set is satisfiable. 250 Otherwise, the byte-range-set is unsatisfiable. 252 In the byte range syntax, first-byte-pos, last-byte-pos, and suffix- 253 length are expressed as decimal number of octets. Since there is no 254 predefined limit to the length of a payload, recipients MUST 255 anticipate potentially large decimal numerals and prevent parsing 256 errors due to integer conversion overflows. 258 2.2. Other Range Units 260 Range units are intended to be extensible. New range units ought to 261 be registered with IANA, as defined in Section 5.1. 263 other-range-unit = token 265 2.3. Accept-Ranges 267 The "Accept-Ranges" header field allows a server to indicate that it 268 supports range requests for the target resource. 270 Accept-Ranges = acceptable-ranges 271 acceptable-ranges = 1#range-unit / "none" 273 An origin server that supports byte-range requests for a given target 274 resource MAY send 276 Accept-Ranges: bytes 278 to indicate what range units are supported. A client MAY generate 279 range requests without having received this header field for the 280 resource involved. Range units are defined in Section 2. 282 A server that does not support any kind of range request for the 283 target resource MAY send 285 Accept-Ranges: none 287 to advise the client not to attempt a range request. 289 3. Range Requests 291 3.1. Range 293 The "Range" header field on a GET request modifies the method 294 semantics to request transfer of only one or more subranges of the 295 selected representation data, rather than the entire selected 296 representation data. 298 Range = byte-ranges-specifier / other-ranges-specifier 299 other-ranges-specifier = other-range-unit "=" other-range-set 300 other-range-set = 1*CHAR 302 A server MAY ignore the Range header field. However, origin servers 303 and intermediate caches ought to support byte ranges when possible, 304 since Range supports efficient recovery from partially failed 305 transfers and partial retrieval of large representations. A server 306 MUST ignore a Range header field received with a request method other 307 than GET. 309 An origin server MUST ignore a Range header field that contains a 310 range unit it does not understand. A proxy MAY discard a Range 311 header field that contains a range unit it does not understand. 313 A server that supports range requests MAY ignore or reject a Range 314 header field that consists of more than two overlapping ranges, or a 315 set of many small ranges that are not listed in ascending order, 316 since both are indications of either a broken client or a deliberate 317 denial of service attack (Section 6.1). A client SHOULD NOT request 318 multiple ranges that are inherently less efficient to process and 319 transfer than a single range that encompasses the same data. 321 A client that is requesting multiple ranges SHOULD list those ranges 322 in ascending order (the order in which they would typically be 323 received in a complete representation) unless there is a specific 324 need to request a later part earlier. For example, a user agent 325 processing a large representation with an internal catalog of parts 326 might need to request later parts first, particularly if the 327 representation consists of pages stored in reverse order and the user 328 agent wishes to transfer one page at a time. 330 The Range header field is evaluated after evaluating the precondition 331 header fields defined in [Part4], and only if the result in absence 332 of the Range header field would be a 200 (OK) response. In other 333 words, Range is ignored when a conditional GET would result in a 304 334 (Not Modified) response. 336 The If-Range header field (Section 3.2) can be used as a precondition 337 to applying the Range header field. 339 If all of the preconditions are true, the server supports the Range 340 header field for the target resource, and the specified range(s) are 341 valid and satisfiable (as defined in Section 2.1), the server SHOULD 342 send a 206 (Partial Content) response with a payload containing one 343 or more partial representations that correspond to the satisfiable 344 ranges requested, as defined in Section 4. 346 If all of the preconditions are true, the server supports the Range 347 header field for the target resource, and the specified range(s) are 348 invalid or unsatisfiable, the server SHOULD send a 416 (Range Not 349 Satisfiable) response. 351 3.2. If-Range 353 If a client has a partial copy of a representation and wishes to have 354 an up-to-date copy of the entire representation, it could use the 355 Range header field with a conditional GET (using either or both of 356 If-Unmodified-Since and If-Match.) However, if the precondition 357 fails because the representation has been modified, the client would 358 then have to make a second request to obtain the entire current 359 representation. 361 The "If-Range" header field allows a client to "short-circuit" the 362 second request. Informally, its meaning is: if the representation is 363 unchanged, send me the part(s) that I am requesting in Range; 364 otherwise, send me the entire representation. 366 If-Range = entity-tag / HTTP-date 368 A client MUST NOT generate an If-Range header field in a request that 369 does not contain a Range header field. A server MUST ignore an If- 370 Range header field received in a request that does not contain a 371 Range header field. An origin server MUST ignore an If-Range header 372 field received in a request for a target resource that does not 373 support Range requests. 375 A client MUST NOT generate an If-Range header field containing an 376 entity-tag that is marked as weak. A client MUST NOT generate an If- 377 Range header field containing an HTTP-date unless the client has no 378 entity-tag for the corresponding representation and the date is a 379 strong validator in the sense defined by Section 2.2.2 of [Part4]. 381 A server that evaluates an If-Range precondition MUST use the strong 382 comparison function when comparing entity-tags (Section 2.3.2 of 383 [Part4]) and MUST evaluate the condition as false if an HTTP-date 384 validator is provided that is not a strong validator in the sense 385 defined by Section 2.2.2 of [Part4]. (A server can distinguish 386 between a valid HTTP-date and any form of entity-tag by examining the 387 first two characters.) 389 If the validator given in the If-Range header field matches the 390 current validator for the selected representation of the target 391 resource, then the server SHOULD process the Range header field as 392 requested. If the validator does not match, the server MUST ignore 393 the Range header field. 395 4. Responses to a Range Request 396 4.1. 206 Partial Content 398 The 206 (Partial Content) status code indicates that the server is 399 successfully fulfilling a range request for the target resource by 400 transferring one or more parts of the selected representation that 401 correspond to the satisfiable ranges found in the request's Range 402 header field (Section 3.1). 404 If a single part is being transferred, the server generating the 206 405 response MUST generate a Content-Range header field, describing what 406 range of the selected representation is enclosed, and a payload 407 consisting of the range. For example: 409 HTTP/1.1 206 Partial Content 410 Date: Wed, 15 Nov 1995 06:25:24 GMT 411 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 412 Content-Range: bytes 21010-47021/47022 413 Content-Length: 26012 414 Content-Type: image/gif 416 ... 26012 bytes of partial image data ... 418 If multiple parts are being transferred, the server generating the 419 206 response MUST generate a "multipart/byteranges" payload, as 420 defined in Appendix A, and a Content-Type header field containing the 421 multipart/byteranges media type and its required boundary parameter. 422 To avoid confusion with single part responses, a server MUST NOT 423 generate a Content-Range header field in the HTTP header section of a 424 multiple part response (this field will be sent in each part 425 instead). 427 Within the header area of each body part in the multipart payload, 428 the server MUST generate a Content-Range header field corresponding 429 to the range being enclosed in that body part. If the selected 430 representation would have had a Content-Type header field in a 200 431 (OK) response, the server SHOULD generate that same Content-Type 432 field in the header area of each body part. For example: 434 HTTP/1.1 206 Partial Content 435 Date: Wed, 15 Nov 1995 06:25:24 GMT 436 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 437 Content-Length: 1741 438 Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES 440 --THIS_STRING_SEPARATES 441 Content-Type: application/pdf 442 Content-Range: bytes 500-999/8000 444 ...the first range... 445 --THIS_STRING_SEPARATES 446 Content-Type: application/pdf 447 Content-Range: bytes 7000-7999/8000 449 ...the second range 450 --THIS_STRING_SEPARATES-- 452 When multiple ranges are requested, a server MAY coalesce any of the 453 ranges that overlap, or that are separated by a gap that is smaller 454 than the overhead of sending multiple parts, regardless of the order 455 in which the corresponding byte-range-spec appeared in the received 456 Range header field. Since the typical overhead between parts of a 457 multipart/byteranges payload is around 80 bytes, depending on the 458 selected representation's media type and the chosen boundary 459 parameter length, it can be less efficient to transfer many small 460 disjoint parts than it is to transfer the entire selected 461 representation. 463 A server MUST NOT generate a multipart response to a request for a 464 single range, since a client that does not request multiple parts 465 might not support multipart responses. However, a server MAY 466 generate a multipart/byteranges payload with only a single body part 467 if multiple ranges were requested and only one range was found to be 468 satisfiable or only one range remained after coalescing. A client 469 that cannot process a multipart/byteranges response MUST NOT generate 470 a request that asks for multiple ranges. 472 When a multipart response payload is generated, the server SHOULD 473 send the parts in the same order that the corresponding byte-range- 474 spec appeared in the received Range header field, excluding those 475 ranges that were deemed unsatisfiable or that were coalesced into 476 other ranges. A client that receives a multipart response MUST 477 inspect the Content-Range header field present in each body part in 478 order to determine which range is contained in that body part; a 479 client cannot rely on receiving the same ranges that it requested, 480 nor the same order that it requested. 482 When a 206 response is generated, the server MUST generate the 483 following header fields, in addition to those required above, if the 484 field would have been sent in a 200 (OK) response to the same 485 request: Date, Cache-Control, ETag, Expires, Content-Location, and 486 Vary. 488 If a 206 is generated in response to a request with an If-Range 489 header field, the sender SHOULD NOT generate other representation 490 header fields beyond those required above, because the client is 491 understood to already have a prior response containing those header 492 fields. Otherwise, the sender MUST generate all of the 493 representation header fields that would have been sent in a 200 (OK) 494 response to the same request. 496 A 206 response is cacheable by default; i.e., unless otherwise 497 indicated by explicit cache controls (see Section 4.2.2 of [Part6]). 499 4.2. Content-Range 501 The "Content-Range" header field is sent in a single part 206 502 (Partial Content) response to indicate the partial range of the 503 selected representation enclosed as the message payload, sent in each 504 part of a multipart 206 response to indicate the range enclosed 505 within each body part, and sent in 416 (Range Not Satisfiable) 506 responses to provide information about the selected representation. 508 Content-Range = byte-content-range 509 / other-content-range 511 byte-content-range = bytes-unit SP 512 ( byte-range-resp / unsatisfied-range ) 514 byte-range-resp = byte-range "/" ( complete-length / "*" ) 515 byte-range = first-byte-pos "-" last-byte-pos 516 unsatisfied-range = "*/" complete-length 518 complete-length = 1*DIGIT 520 other-content-range = other-range-unit SP other-range-resp 521 other-range-resp = *CHAR 523 If a 206 (Partial Content) response contains a Content-Range header 524 field with a range unit (Section 2) that the recipient does not 525 understand, the recipient MUST NOT attempt to recombine it with a 526 stored representation. A proxy that receives such a message SHOULD 527 forward it downstream. 529 For byte ranges, a sender SHOULD indicate the complete length of the 530 representation from which the range has been extracted, unless the 531 complete length is unknown or difficult to determine. An asterisk 532 character ("*") in place of the complete-length indicates that the 533 representation length was unknown when the header field was 534 generated. 536 The following example illustrates when the complete length of the 537 selected representation is known by the sender to be 1234 bytes: 539 Content-Range: bytes 42-1233/1234 541 and this second example illustrates when the complete length is 542 unknown: 544 Content-Range: bytes 42-1233/* 546 A Content-Range field value is invalid if it contains a byte-range- 547 resp that has a last-byte-pos value less than its first-byte-pos 548 value, or a complete-length value less than or equal to its last- 549 byte-pos value. The recipient of an invalid Content-Range MUST NOT 550 attempt to recombine the received content with a stored 551 representation. 553 A server generating a 416 (Range Not Satisfiable) response to a byte 554 range request SHOULD send a Content-Range header field with an 555 unsatisfied-range value, as in the following example: 557 Content-Range: bytes */1234 559 The complete-length in a 416 response indicates the current length of 560 the selected representation. 562 The "Content-Range" header field has no meaning for status codes that 563 do not explicitly describe its semantic. For this specification, 564 only the 206 (Partial Content) and 416 (Range Not Satisfiable) status 565 codes describe a meaning for Content-Range. 567 The following are examples of Content-Range values in which the 568 selected representation contains a total of 1234 bytes: 570 o The first 500 bytes: 572 Content-Range: bytes 0-499/1234 574 o The second 500 bytes: 576 Content-Range: bytes 500-999/1234 578 o All except for the first 500 bytes: 580 Content-Range: bytes 500-1233/1234 582 o The last 500 bytes: 584 Content-Range: bytes 734-1233/1234 586 4.3. Combining Ranges 588 A response might transfer only a subrange of a representation if the 589 connection closed prematurely or if the request used one or more 590 Range specifications. After several such transfers, a client might 591 have received several ranges of the same representation. These 592 ranges can only be safely combined if they all have in common the 593 same strong validator (Section 2.1 of [Part4]). 595 A client that has received multiple partial responses to GET requests 596 on a target resource MAY combine those responses into a larger 597 continuous range if they share the same strong validator. 599 If the most recent response is an incomplete 200 (OK) response, then 600 the header fields of that response are used for any combined response 601 and replace those of the matching stored responses. 603 If the most recent response is a 206 (Partial Content) response and 604 at least one of the matching stored responses is a 200 (OK), then the 605 combined response header fields consist of the most recent 200 606 response's header fields. If all of the matching stored responses 607 are 206 responses, then the stored response with the most recent 608 header fields is used as the source of header fields for the combined 609 response, except that the client MUST use other header fields 610 provided in the new response, aside from Content-Range, to replace 611 all instances of the corresponding header fields in the stored 612 response. 614 The combined response message body consists of the union of partial 615 content ranges in the new response and each of the selected 616 responses. If the union consists of the entire range of the 617 representation, then the client MUST process the combined response as 618 if it were a complete 200 (OK) response, including a Content-Length 619 header field that reflects the complete length. Otherwise, the 620 client MUST process the set of continuous ranges as one of the 621 following: an incomplete 200 (OK) response if the combined response 622 is a prefix of the representation, a single 206 (Partial Content) 623 response containing a multipart/byteranges body, or multiple 206 624 (Partial Content) responses, each with one continuous range that is 625 indicated by a Content-Range header field. 627 4.4. 416 Range Not Satisfiable 629 The 416 (Range Not Satisfiable) status code indicates that none of 630 the ranges in the request's Range header field (Section 3.1) overlap 631 the current extent of the selected resource or that the set of ranges 632 requested has been rejected due to invalid ranges or an excessive 633 request of small or overlapping ranges. 635 For byte ranges, failing to overlap the current extent means that the 636 first-byte-pos of all of the byte-range-spec values were greater than 637 the current length of the selected representation. When this status 638 code is generated in response to a byte range request, the sender 639 SHOULD generate a Content-Range header field specifying the current 640 length of the selected representation (Section 4.2). 642 For example: 644 HTTP/1.1 416 Range Not Satisfiable 645 Date: Fri, 20 Jan 2012 15:41:54 GMT 646 Content-Range: bytes */47022 648 Note: Because servers are free to ignore Range, many 649 implementations will simply respond with the entire selected 650 representation in a 200 (OK) response. That is partly because 651 most clients are prepared to receive a 200 (OK) to complete the 652 task (albeit less efficiently) and partly because clients might 653 not stop making an invalid partial request until they have 654 received a complete representation. Thus, clients cannot depend 655 on receiving a 416 (Range Not Satisfiable) response even when it 656 is most appropriate. 658 5. IANA Considerations 660 5.1. Range Unit Registry 662 The HTTP Range Unit Registry defines the name space for the range 663 unit names and refers to their corresponding specifications. The 664 registry will be created and maintained at (the suggested URI) 665 . 667 5.1.1. Procedure 669 Registration of an HTTP Range Unit MUST include the following fields: 671 o Name 673 o Description 674 o Pointer to specification text 676 Values to be added to this name space require IETF Review (see 677 [RFC5226], Section 4.1). 679 5.1.2. Registrations 681 The initial HTTP Range Unit Registry shall contain the registrations 682 below: 684 +-------------+---------------------------------------+-------------+ 685 | Range Unit | Description | Reference | 686 | Name | | | 687 +-------------+---------------------------------------+-------------+ 688 | bytes | a range of octets | Section 2.1 | 689 | none | reserved as keyword, indicating no | Section 2.3 | 690 | | ranges are supported | | 691 +-------------+---------------------------------------+-------------+ 693 The change controller is: "IETF (iesg@ietf.org) - Internet 694 Engineering Task Force". 696 5.2. Status Code Registration 698 The HTTP Status Code Registry located at 699 shall be updated 700 with the registrations below: 702 +-------+-----------------------+-------------+ 703 | Value | Description | Reference | 704 +-------+-----------------------+-------------+ 705 | 206 | Partial Content | Section 4.1 | 706 | 416 | Range Not Satisfiable | Section 4.4 | 707 +-------+-----------------------+-------------+ 709 5.3. Header Field Registration 711 HTTP header fields are registered within the Message Header Field 712 Registry maintained at . 715 This document defines the following HTTP header fields, so their 716 associated registry entries shall be updated according to the 717 permanent registrations below (see [BCP90]): 719 +-------------------+----------+----------+-------------+ 720 | Header Field Name | Protocol | Status | Reference | 721 +-------------------+----------+----------+-------------+ 722 | Accept-Ranges | http | standard | Section 2.3 | 723 | Content-Range | http | standard | Section 4.2 | 724 | If-Range | http | standard | Section 3.2 | 725 | Range | http | standard | Section 3.1 | 726 +-------------------+----------+----------+-------------+ 728 The change controller is: "IETF (iesg@ietf.org) - Internet 729 Engineering Task Force". 731 5.4. Internet Media Type Registration 733 IANA maintains the registry of Internet media types [BCP13] at 734 . 736 This document serves as the specification for the Internet media type 737 "multipart/byteranges". The following is to be registered with IANA. 739 5.4.1. Internet Media Type multipart/byteranges 741 Type name: multipart 743 Subtype name: byteranges 745 Required parameters: boundary 747 Optional parameters: none 749 Encoding considerations: only "7bit", "8bit", or "binary" are 750 permitted 752 Security considerations: none 754 Interoperability considerations: none 756 Published specification: This specification (see Appendix A). 758 Applications that use this media type: HTTP components supporting 759 multiple ranges in a single request. 761 Additional information: 763 Magic number(s): none 764 File extension(s): none 766 Macintosh file type code(s): none 768 Person and email address to contact for further information: See 769 Authors Section. 771 Intended usage: COMMON 773 Restrictions on usage: none 775 Author: See Authors Section. 777 Change controller: IESG 779 6. Security Considerations 781 This section is meant to inform developers, information providers, 782 and users of known security concerns specific to the HTTP/1.1 range 783 request mechanisms. More general security considerations are 784 addressed in HTTP messaging [Part1] and semantics [Part2]. 786 6.1. Denial of Service Attacks using Range 788 Unconstrained multiple range requests are susceptible to denial of 789 service attacks because the effort required to request many 790 overlapping ranges of the same data is tiny compared to the time, 791 memory, and bandwidth consumed by attempting to serve the requested 792 data in many parts. Servers ought to ignore, coalesce, or reject 793 egregious range requests, such as requests for more than two 794 overlapping ranges or for many small ranges in a single set, 795 particularly when the ranges are requested out of order for no 796 apparent reason. Multipart range requests are not designed to 797 support random access. 799 7. Acknowledgments 801 See Section 10 of [Part1]. 803 8. References 805 8.1. Normative References 807 [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 808 Protocol (HTTP/1.1): Message Syntax and Routing", 809 draft-ietf-httpbis-p1-messaging-25 (work in progress), 810 November 2013. 812 [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 813 Protocol (HTTP/1.1): Semantics and Content", 814 draft-ietf-httpbis-p2-semantics-25 (work in progress), 815 November 2013. 817 [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 818 Protocol (HTTP/1.1): Conditional Requests", 819 draft-ietf-httpbis-p4-conditional-25 (work in progress), 820 November 2013. 822 [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 823 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 824 draft-ietf-httpbis-p6-cache-25 (work in progress), 825 November 2013. 827 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 828 Extensions (MIME) Part Two: Media Types", RFC 2046, 829 November 1996. 831 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 832 Requirement Levels", BCP 14, RFC 2119, March 1997. 834 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 835 Specifications: ABNF", STD 68, RFC 5234, January 2008. 837 8.2. Informative References 839 [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type 840 Specifications and Registration Procedures", BCP 13, 841 RFC 6838, January 2013. 843 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration 844 Procedures for Message Header Fields", BCP 90, RFC 3864, 845 September 2004. 847 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 848 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 849 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 851 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 852 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 853 May 2008. 855 Appendix A. Internet Media Type multipart/byteranges 857 When a 206 (Partial Content) response message includes the content of 858 multiple ranges, they are transmitted as body parts in a multipart 859 message body ([RFC2046], Section 5.1) with the media type of 860 "multipart/byteranges". 862 The multipart/byteranges media type includes one or more body parts, 863 each with its own Content-Type and Content-Range fields. The 864 required boundary parameter specifies the boundary string used to 865 separate each body part. 867 Implementation Notes: 869 1. Additional CRLFs might precede the first boundary string in the 870 body. 872 2. Although [RFC2046] permits the boundary string to be quoted, some 873 existing implementations handle a quoted boundary string 874 incorrectly. 876 3. A number of clients and servers were coded to an early draft of 877 the byteranges specification that used a media type of multipart/ 878 x-byteranges, which is almost (but not quite) compatible with 879 this type. 881 Despite the name, the "multipart/byteranges" media type is not 882 limited to byte ranges. The following example uses an "exampleunit" 883 range unit: 885 HTTP/1.1 206 Partial Content 886 Date: Tue, 14 Nov 1995 06:25:24 GMT 887 Last-Modified: Tue, 14 July 04:58:08 GMT 888 Content-Length: 2331785 889 Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES 891 --THIS_STRING_SEPARATES 892 Content-Type: video/example 893 Content-Range: exampleunit 1.2-4.3/25 895 ...the first range... 896 --THIS_STRING_SEPARATES 897 Content-Type: video/example 898 Content-Range: exampleunit 11.2-14.3/25 900 ...the second range 901 --THIS_STRING_SEPARATES-- 903 Appendix B. Changes from RFC 2616 905 Servers are given more leeway in how they respond to a range request, 906 in order to mitigate abuse by malicious (or just greedy) clients. 907 (Section 3.1) 908 A weak validator cannot be used in a 206 response. (Section 4.1) 910 The Content-Range header field only has meaning when the status code 911 explicitly defines its use. (Section 4.2) 913 This specification introduces a Range Unit Registry. (Section 5.1) 915 multipart/byteranges can consist of a single part. (Appendix A) 917 Appendix C. Imported ABNF 919 The following core rules are included by reference, as defined in 920 Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), 921 CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double 922 quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 923 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII 924 character). 926 Note that all rules derived from token are to be compared case- 927 insensitively, like range-unit and acceptable-ranges. 929 The rules below are defined in [Part1]: 931 OWS = 932 token = 934 The rules below are defined in other parts: 936 HTTP-date = 937 entity-tag = 939 Appendix D. Collected ABNF 941 In the collected ABNF below, list rules are expanded as per Section 942 1.2 of [Part1]. 944 Accept-Ranges = acceptable-ranges 946 Content-Range = byte-content-range / other-content-range 948 HTTP-date = 950 If-Range = entity-tag / HTTP-date 952 OWS = 954 Range = byte-ranges-specifier / other-ranges-specifier 956 acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS 957 range-unit ] ) ) / "none" 959 byte-content-range = bytes-unit SP ( byte-range-resp / 960 unsatisfied-range ) 961 byte-range = first-byte-pos "-" last-byte-pos 962 byte-range-resp = byte-range "/" ( complete-length / "*" ) 963 byte-range-set = *( "," OWS ) ( byte-range-spec / 964 suffix-byte-range-spec ) *( OWS "," [ OWS ( byte-range-spec / 965 suffix-byte-range-spec ) ] ) 966 byte-range-spec = first-byte-pos "-" [ last-byte-pos ] 967 byte-ranges-specifier = bytes-unit "=" byte-range-set 968 bytes-unit = "bytes" 970 complete-length = 1*DIGIT 972 entity-tag = 974 first-byte-pos = 1*DIGIT 976 last-byte-pos = 1*DIGIT 978 other-content-range = other-range-unit SP other-range-resp 979 other-range-resp = *CHAR 980 other-range-set = 1*CHAR 981 other-range-unit = token 982 other-ranges-specifier = other-range-unit "=" other-range-set 984 range-unit = bytes-unit / other-range-unit 986 suffix-byte-range-spec = "-" suffix-length 987 suffix-length = 1*DIGIT 989 token = 991 unsatisfied-range = "*/" complete-length 993 Appendix E. Change Log (to be removed by RFC Editor before publication) 995 Changes up to the IETF Last Call draft are summarized in . 998 E.1. Since draft-ietf-httpbis-p5-range-24 1000 Closed issues: 1002 o : "APPSDIR 1003 review of draft-ietf-httpbis-p5-range-24" 1005 o : "integer value 1006 parsing" 1008 o : "broken 1009 sentence in description of 206" 1011 Index 1013 2 1014 206 Partial Content (status code) 10 1016 4 1017 416 Range Not Satisfiable (status code) 15 1019 A 1020 Accept-Ranges header field 7 1022 C 1023 Content-Range header field 12 1025 G 1026 Grammar 1027 Accept-Ranges 7 1028 acceptable-ranges 7 1029 byte-content-range 12 1030 byte-range 12 1031 byte-range-resp 12 1032 byte-range-set 5 1033 byte-range-spec 5 1034 byte-ranges-specifier 5 1035 bytes-unit 5 1036 complete-length 12 1037 Content-Range 12 1038 first-byte-pos 5 1039 If-Range 9 1040 last-byte-pos 5 1041 other-content-range 12 1042 other-range-resp 12 1043 other-range-unit 5, 7 1044 Range 7 1045 range-unit 5 1046 ranges-specifier 5 1047 suffix-byte-range-spec 6 1048 suffix-length 6 1049 unsatisfied-range 12 1051 I 1052 If-Range header field 9 1054 M 1055 Media Type 1056 multipart/byteranges 17, 19 1057 multipart/x-byteranges 20 1058 multipart/byteranges Media Type 17, 19 1059 multipart/x-byteranges Media Type 20 1061 R 1062 Range header field 7 1064 Authors' Addresses 1066 Roy T. Fielding (editor) 1067 Adobe Systems Incorporated 1068 345 Park Ave 1069 San Jose, CA 95110 1070 USA 1072 EMail: fielding@gbiv.com 1073 URI: http://roy.gbiv.com/ 1075 Yves Lafon (editor) 1076 World Wide Web Consortium 1077 W3C / ERCIM 1078 2004, rte des Lucioles 1079 Sophia-Antipolis, AM 06902 1080 France 1082 EMail: ylafon@w3.org 1083 URI: http://www.raubacapeu.net/people/yves/ 1084 Julian F. Reschke (editor) 1085 greenbytes GmbH 1086 Hafenweg 16 1087 Muenster, NW 48155 1088 Germany 1090 EMail: julian.reschke@greenbytes.de 1091 URI: http://greenbytes.de/tech/webdav/