idnits 2.17.1 draft-ietf-httpbis-range-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, 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 (April 3, 2018) is 2213 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: 'RFC7233' is defined on line 872, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-cache-00 -- Possible downref: Normative reference to a draft: ref. 'CACHING' == Outdated reference: A later version (-01) exists of draft-ietf-httpbis-conditional-00 == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-messaging-00 -- Possible downref: Normative reference to a draft: ref. 'MESSGNG' == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-semantics-00 -- Possible downref: Normative reference to a draft: ref. 'SEMNTCS' -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 7233 (Obsoleted by RFC 9110) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP Working Group R. Fielding, Ed. 3 Internet-Draft Adobe 4 Obsoletes: 7233 (if approved) M. Nottingham, Ed. 5 Intended status: Standards Track Fastly 6 Expires: October 5, 2018 J. Reschke, Ed. 7 greenbytes 8 April 3, 2018 10 Hypertext Transfer Protocol (HTTP): Range Requests 11 draft-ietf-httpbis-range-00 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 This document obsoletes RFC 7233. 22 Editorial Note 24 This note is to be removed before publishing as an RFC. 26 Discussion of this draft takes place on the HTTP working group 27 mailing list (ietf-http-wg@w3.org), which is archived at 28 . 30 Working Group information can be found at ; 31 source code and issues list for this draft can be found at 32 . 34 The changes in this draft are summarized in Appendix E.1. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on October 5, 2018. 53 Copyright Notice 55 Copyright (c) 2018 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 This document may contain material from IETF Documents or IETF 69 Contributions published or made publicly available before November 70 10, 2008. The person(s) controlling the copyright in some of this 71 material may not have granted the IETF Trust the right to allow 72 modifications of such material outside the IETF Standards Process. 73 Without obtaining an adequate license from the person(s) controlling 74 the copyright in such materials, this document may not be modified 75 outside the IETF Standards Process, and derivative works of it may 76 not be created outside the IETF Standards Process, except to format 77 it for publication as an RFC or to translate it into languages other 78 than English. 80 Table of Contents 82 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 83 1.1. Conformance and Error Handling . . . . . . . . . . . . . 4 84 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 85 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 4 86 2.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . . . 4 87 2.2. Other Range Units . . . . . . . . . . . . . . . . . . . . 6 88 2.3. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 6 89 3. Range Requests . . . . . . . . . . . . . . . . . . . . . . . 7 90 3.1. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 7 91 3.2. If-Range . . . . . . . . . . . . . . . . . . . . . . . . 8 92 4. Responses to a Range Request . . . . . . . . . . . . . . . . 9 93 4.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 9 94 4.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 11 95 4.3. Combining Ranges . . . . . . . . . . . . . . . . . . . . 13 96 4.4. 416 Range Not Satisfiable . . . . . . . . . . . . . . . . 14 97 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 98 5.1. Range Unit Registry . . . . . . . . . . . . . . . . . . . 15 99 5.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 15 100 5.1.2. Registrations . . . . . . . . . . . . . . . . . . . . 15 101 5.2. Status Code Registration . . . . . . . . . . . . . . . . 16 102 5.3. Header Field Registration . . . . . . . . . . . . . . . . 16 103 5.4. Internet Media Type Registration . . . . . . . . . . . . 16 104 5.4.1. Internet Media Type multipart/byteranges . . . . . . 16 105 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 106 6.1. Denial-of-Service Attacks Using Range . . . . . . . . . . 18 107 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 108 7.1. Normative References . . . . . . . . . . . . . . . . . . 18 109 7.2. Informative References . . . . . . . . . . . . . . . . . 19 110 Appendix A. Internet Media Type multipart/byteranges . . . . . . 20 111 Appendix B. Changes from RFC 7233 . . . . . . . . . . . . . . . 21 112 Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . 21 113 Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 21 114 Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 23 115 E.1. Since RFC 7233 . . . . . . . . . . . . . . . . . . . . . 23 116 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 117 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 24 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 120 1. Introduction 122 Hypertext Transfer Protocol (HTTP) clients often encounter 123 interrupted data transfers as a result of canceled requests or 124 dropped connections. When a client has stored a partial 125 representation, it is desirable to request the remainder of that 126 representation in a subsequent request rather than transfer the 127 entire representation. Likewise, devices with limited local storage 128 might benefit from being able to request only a subset of a larger 129 representation, such as a single page of a very large document, or 130 the dimensions of an embedded image. 132 This document defines HTTP/1.1 range requests, partial responses, and 133 the multipart/byteranges media type. Range requests are an OPTIONAL 134 feature of HTTP, designed so that recipients not implementing this 135 feature (or not supporting it for the target resource) can respond as 136 if it is a normal GET request without impacting interoperability. 137 Partial responses are indicated by a distinct status code to not be 138 mistaken for full responses by caches that might not implement the 139 feature. 141 Although the range request mechanism is designed to allow for 142 extensible range types, this specification only defines requests for 143 byte ranges. 145 This specification obsoletes RFC 7233, with the changes being 146 summarized in Appendix B. 148 1.1. Conformance and Error Handling 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in [RFC2119]. 154 Conformance criteria and considerations regarding error handling are 155 defined in Section 2.5 of [MESSGNG]. 157 1.2. Syntax Notation 159 This specification uses the Augmented Backus-Naur Form (ABNF) 160 notation of [RFC5234] with a list extension, defined in Section 7 of 161 [MESSGNG], that allows for compact definition of comma-separated 162 lists using a '#' operator (similar to how the '*' operator indicates 163 repetition). Appendix C describes rules imported from other 164 documents. Appendix D shows the collected grammar with all list 165 operators expanded to standard ABNF notation. 167 2. Range Units 169 A representation can be partitioned into subranges according to 170 various structural units, depending on the structure inherent in the 171 representation's media type. This "range unit" is used in the 172 Accept-Ranges (Section 2.3) response header field to advertise 173 support for range requests, the Range (Section 3.1) request header 174 field to delineate the parts of a representation that are requested, 175 and the Content-Range (Section 4.2) payload header field to describe 176 which part of a representation is being transferred. 178 range-unit = bytes-unit / other-range-unit 180 2.1. Byte Ranges 182 Since representation data is transferred in payloads as a sequence of 183 octets, a byte range is a meaningful substructure for any 184 representation transferable over HTTP (Section 3 of [SEMNTCS]). The 185 "bytes" range unit is defined for expressing subranges of the data's 186 octet sequence. 188 bytes-unit = "bytes" 190 A byte-range request can specify a single range of bytes or a set of 191 ranges within a single representation. 193 byte-ranges-specifier = bytes-unit "=" byte-range-set 194 byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec ) 195 byte-range-spec = first-byte-pos "-" [ last-byte-pos ] 196 first-byte-pos = 1*DIGIT 197 last-byte-pos = 1*DIGIT 199 The first-byte-pos value in a byte-range-spec gives the byte-offset 200 of the first byte in a range. The last-byte-pos value gives the 201 byte-offset of the last byte in the range; that is, the byte 202 positions specified are inclusive. Byte offsets start at zero. 204 Examples of byte-ranges-specifier values: 206 o The first 500 bytes (byte offsets 0-499, inclusive): 208 bytes=0-499 210 o The second 500 bytes (byte offsets 500-999, inclusive): 212 bytes=500-999 214 A byte-range-spec is invalid if the last-byte-pos value is present 215 and less than the first-byte-pos. 217 A client can limit the number of bytes requested without knowing the 218 size of the selected representation. If the last-byte-pos value is 219 absent, or if the value is greater than or equal to the current 220 length of the representation data, the byte range is interpreted as 221 the remainder of the representation (i.e., the server replaces the 222 value of last-byte-pos with a value that is one less than the current 223 length of the selected representation). 225 A client can request the last N bytes of the selected representation 226 using a suffix-byte-range-spec. 228 suffix-byte-range-spec = "-" suffix-length 229 suffix-length = 1*DIGIT 231 If the selected representation is shorter than the specified suffix- 232 length, the entire representation is used. 234 Additional examples, assuming a representation of length 10000: 236 o The final 500 bytes (byte offsets 9500-9999, inclusive): 238 bytes=-500 240 Or: 242 bytes=9500- 244 o The first and last bytes only (bytes 0 and 9999): 246 bytes=0-0,-1 248 o Other valid (but not canonical) specifications of the second 500 249 bytes (byte offsets 500-999, inclusive): 251 bytes=500-600,601-999 252 bytes=500-700,601-999 254 If a valid byte-range-set includes at least one byte-range-spec with 255 a first-byte-pos that is less than the current length of the 256 representation, or at least one suffix-byte-range-spec with a non- 257 zero suffix-length, then the byte-range-set is satisfiable. 258 Otherwise, the byte-range-set is unsatisfiable. 260 In the byte-range syntax, first-byte-pos, last-byte-pos, and suffix- 261 length are expressed as decimal number of octets. Since there is no 262 predefined limit to the length of a payload, recipients MUST 263 anticipate potentially large decimal numerals and prevent parsing 264 errors due to integer conversion overflows. 266 2.2. Other Range Units 268 Range units are intended to be extensible. New range units ought to 269 be registered with IANA, as defined in Section 5.1. 271 other-range-unit = token 273 2.3. Accept-Ranges 275 The "Accept-Ranges" header field allows a server to indicate that it 276 supports range requests for the target resource. 278 Accept-Ranges = acceptable-ranges 279 acceptable-ranges = 1#range-unit / "none" 281 An origin server that supports byte-range requests for a given target 282 resource MAY send 284 Accept-Ranges: bytes 286 to indicate what range units are supported. A client MAY generate 287 range requests without having received this header field for the 288 resource involved. Range units are defined in Section 2. 290 A server that does not support any kind of range request for the 291 target resource MAY send 293 Accept-Ranges: none 295 to advise the client not to attempt a range request. 297 3. Range Requests 299 3.1. Range 301 The "Range" header field on a GET request modifies the method 302 semantics to request transfer of only one or more subranges of the 303 selected representation data, rather than the entire selected 304 representation data. 306 Range = byte-ranges-specifier / other-ranges-specifier 307 other-ranges-specifier = other-range-unit "=" other-range-set 308 other-range-set = 1*VCHAR 310 A server MAY ignore the Range header field. However, origin servers 311 and intermediate caches ought to support byte ranges when possible, 312 since Range supports efficient recovery from partially failed 313 transfers and partial retrieval of large representations. A server 314 MUST ignore a Range header field received with a request method other 315 than GET. 317 An origin server MUST ignore a Range header field that contains a 318 range unit it does not understand. A proxy MAY discard a Range 319 header field that contains a range unit it does not understand. 321 A server that supports range requests MAY ignore or reject a Range 322 header field that consists of more than two overlapping ranges, or a 323 set of many small ranges that are not listed in ascending order, 324 since both are indications of either a broken client or a deliberate 325 denial-of-service attack (Section 6.1). A client SHOULD NOT request 326 multiple ranges that are inherently less efficient to process and 327 transfer than a single range that encompasses the same data. 329 A client that is requesting multiple ranges SHOULD list those ranges 330 in ascending order (the order in which they would typically be 331 received in a complete representation) unless there is a specific 332 need to request a later part earlier. For example, a user agent 333 processing a large representation with an internal catalog of parts 334 might need to request later parts first, particularly if the 335 representation consists of pages stored in reverse order and the user 336 agent wishes to transfer one page at a time. 338 The Range header field is evaluated after evaluating the precondition 339 header fields defined in [CONDTNL], and only if the result in absence 340 of the Range header field would be a 200 (OK) response. In other 341 words, Range is ignored when a conditional GET would result in a 304 342 (Not Modified) response. 344 The If-Range header field (Section 3.2) can be used as a precondition 345 to applying the Range header field. 347 If all of the preconditions are true, the server supports the Range 348 header field for the target resource, and the specified range(s) are 349 valid and satisfiable (as defined in Section 2.1), the server SHOULD 350 send a 206 (Partial Content) response with a payload containing one 351 or more partial representations that correspond to the satisfiable 352 ranges requested, as defined in Section 4. 354 If all of the preconditions are true, the server supports the Range 355 header field for the target resource, and the specified range(s) are 356 invalid or unsatisfiable, the server SHOULD send a 416 (Range Not 357 Satisfiable) response. 359 3.2. If-Range 361 If a client has a partial copy of a representation and wishes to have 362 an up-to-date copy of the entire representation, it could use the 363 Range header field with a conditional GET (using either or both of 364 If-Unmodified-Since and If-Match.) However, if the precondition 365 fails because the representation has been modified, the client would 366 then have to make a second request to obtain the entire current 367 representation. 369 The "If-Range" header field allows a client to "short-circuit" the 370 second request. Informally, its meaning is as follows: if the 371 representation is unchanged, send me the part(s) that I am requesting 372 in Range; otherwise, send me the entire representation. 374 If-Range = entity-tag / HTTP-date 376 A client MUST NOT generate an If-Range header field in a request that 377 does not contain a Range header field. A server MUST ignore an If- 378 Range header field received in a request that does not contain a 379 Range header field. An origin server MUST ignore an If-Range header 380 field received in a request for a target resource that does not 381 support Range requests. 383 A client MUST NOT generate an If-Range header field containing an 384 entity-tag that is marked as weak. A client MUST NOT generate an If- 385 Range header field containing an HTTP-date unless the client has no 386 entity-tag for the corresponding representation and the date is a 387 strong validator in the sense defined by Section 2.2.2 of [CONDTNL]. 389 A server that evaluates an If-Range precondition MUST use the strong 390 comparison function when comparing entity-tags (Section 2.3.2 of 391 [CONDTNL]) and MUST evaluate the condition as false if an HTTP-date 392 validator is provided that is not a strong validator in the sense 393 defined by Section 2.2.2 of [CONDTNL]. A valid entity-tag can be 394 distinguished from a valid HTTP-date by examining the first two 395 characters for a DQUOTE. 397 If the validator given in the If-Range header field matches the 398 current validator for the selected representation of the target 399 resource, then the server SHOULD process the Range header field as 400 requested. If the validator does not match, the server MUST ignore 401 the Range header field. Note that this comparison by exact match, 402 including when the validator is an HTTP-date, differs from the 403 "earlier than or equal to" comparison used when evaluating an If- 404 Unmodified-Since conditional. 406 4. Responses to a Range Request 408 4.1. 206 Partial Content 410 The 206 (Partial Content) status code indicates that the server is 411 successfully fulfilling a range request for the target resource by 412 transferring one or more parts of the selected representation that 413 correspond to the satisfiable ranges found in the request's Range 414 header field (Section 3.1). 416 If a single part is being transferred, the server generating the 206 417 response MUST generate a Content-Range header field, describing what 418 range of the selected representation is enclosed, and a payload 419 consisting of the range. For example: 421 HTTP/1.1 206 Partial Content 422 Date: Wed, 15 Nov 1995 06:25:24 GMT 423 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 424 Content-Range: bytes 21010-47021/47022 425 Content-Length: 26012 426 Content-Type: image/gif 428 ... 26012 bytes of partial image data ... 430 If multiple parts are being transferred, the server generating the 431 206 response MUST generate a "multipart/byteranges" payload, as 432 defined in Appendix A, and a Content-Type header field containing the 433 multipart/byteranges media type and its required boundary parameter. 435 To avoid confusion with single-part responses, a server MUST NOT 436 generate a Content-Range header field in the HTTP header section of a 437 multiple part response (this field will be sent in each part 438 instead). 440 Within the header area of each body part in the multipart payload, 441 the server MUST generate a Content-Range header field corresponding 442 to the range being enclosed in that body part. If the selected 443 representation would have had a Content-Type header field in a 200 444 (OK) response, the server SHOULD generate that same Content-Type 445 field in the header area of each body part. For example: 447 HTTP/1.1 206 Partial Content 448 Date: Wed, 15 Nov 1995 06:25:24 GMT 449 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 450 Content-Length: 1741 451 Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES 453 --THIS_STRING_SEPARATES 454 Content-Type: application/pdf 455 Content-Range: bytes 500-999/8000 457 ...the first range... 458 --THIS_STRING_SEPARATES 459 Content-Type: application/pdf 460 Content-Range: bytes 7000-7999/8000 462 ...the second range 463 --THIS_STRING_SEPARATES-- 465 When multiple ranges are requested, a server MAY coalesce any of the 466 ranges that overlap, or that are separated by a gap that is smaller 467 than the overhead of sending multiple parts, regardless of the order 468 in which the corresponding byte-range-spec appeared in the received 469 Range header field. Since the typical overhead between parts of a 470 multipart/byteranges payload is around 80 bytes, depending on the 471 selected representation's media type and the chosen boundary 472 parameter length, it can be less efficient to transfer many small 473 disjoint parts than it is to transfer the entire selected 474 representation. 476 A server MUST NOT generate a multipart response to a request for a 477 single range, since a client that does not request multiple parts 478 might not support multipart responses. However, a server MAY 479 generate a multipart/byteranges payload with only a single body part 480 if multiple ranges were requested and only one range was found to be 481 satisfiable or only one range remained after coalescing. A client 482 that cannot process a multipart/byteranges response MUST NOT generate 483 a request that asks for multiple ranges. 485 When a multipart response payload is generated, the server SHOULD 486 send the parts in the same order that the corresponding byte-range- 487 spec appeared in the received Range header field, excluding those 488 ranges that were deemed unsatisfiable or that were coalesced into 489 other ranges. A client that receives a multipart response MUST 490 inspect the Content-Range header field present in each body part in 491 order to determine which range is contained in that body part; a 492 client cannot rely on receiving the same ranges that it requested, 493 nor the same order that it requested. 495 When a 206 response is generated, the server MUST generate the 496 following header fields, in addition to those required above, if the 497 field would have been sent in a 200 (OK) response to the same 498 request: Date, Cache-Control, ETag, Expires, Content-Location, and 499 Vary. 501 If a 206 is generated in response to a request with an If-Range 502 header field, the sender SHOULD NOT generate other representation 503 header fields beyond those required above, because the client is 504 understood to already have a prior response containing those header 505 fields. Otherwise, the sender MUST generate all of the 506 representation header fields that would have been sent in a 200 (OK) 507 response to the same request. 509 A 206 response is cacheable by default; i.e., unless otherwise 510 indicated by explicit cache controls (see Section 4.2.2 of 511 [CACHING]). 513 4.2. Content-Range 515 The "Content-Range" header field is sent in a single part 206 516 (Partial Content) response to indicate the partial range of the 517 selected representation enclosed as the message payload, sent in each 518 part of a multipart 206 response to indicate the range enclosed 519 within each body part, and sent in 416 (Range Not Satisfiable) 520 responses to provide information about the selected representation. 522 Content-Range = byte-content-range 523 / other-content-range 525 byte-content-range = bytes-unit SP 526 ( byte-range-resp / unsatisfied-range ) 528 byte-range-resp = byte-range "/" ( complete-length / "*" ) 529 byte-range = first-byte-pos "-" last-byte-pos 530 unsatisfied-range = "*/" complete-length 532 complete-length = 1*DIGIT 534 other-content-range = other-range-unit SP other-range-resp 535 other-range-resp = *CHAR 537 If a 206 (Partial Content) response contains a Content-Range header 538 field with a range unit (Section 2) that the recipient does not 539 understand, the recipient MUST NOT attempt to recombine it with a 540 stored representation. A proxy that receives such a message SHOULD 541 forward it downstream. 543 For byte ranges, a sender SHOULD indicate the complete length of the 544 representation from which the range has been extracted, unless the 545 complete length is unknown or difficult to determine. An asterisk 546 character ("*") in place of the complete-length indicates that the 547 representation length was unknown when the header field was 548 generated. 550 The following example illustrates when the complete length of the 551 selected representation is known by the sender to be 1234 bytes: 553 Content-Range: bytes 42-1233/1234 555 and this second example illustrates when the complete length is 556 unknown: 558 Content-Range: bytes 42-1233/* 560 A Content-Range field value is invalid if it contains a byte-range- 561 resp that has a last-byte-pos value less than its first-byte-pos 562 value, or a complete-length value less than or equal to its last- 563 byte-pos value. The recipient of an invalid Content-Range MUST NOT 564 attempt to recombine the received content with a stored 565 representation. 567 A server generating a 416 (Range Not Satisfiable) response to a byte- 568 range request SHOULD send a Content-Range header field with an 569 unsatisfied-range value, as in the following example: 571 Content-Range: bytes */1234 573 The complete-length in a 416 response indicates the current length of 574 the selected representation. 576 The Content-Range header field has no meaning for status codes that 577 do not explicitly describe its semantic. For this specification, 578 only the 206 (Partial Content) and 416 (Range Not Satisfiable) status 579 codes describe a meaning for Content-Range. 581 The following are examples of Content-Range values in which the 582 selected representation contains a total of 1234 bytes: 584 o The first 500 bytes: 586 Content-Range: bytes 0-499/1234 588 o The second 500 bytes: 590 Content-Range: bytes 500-999/1234 592 o All except for the first 500 bytes: 594 Content-Range: bytes 500-1233/1234 596 o The last 500 bytes: 598 Content-Range: bytes 734-1233/1234 600 4.3. Combining Ranges 602 A response might transfer only a subrange of a representation if the 603 connection closed prematurely or if the request used one or more 604 Range specifications. After several such transfers, a client might 605 have received several ranges of the same representation. These 606 ranges can only be safely combined if they all have in common the 607 same strong validator (Section 2.1 of [CONDTNL]). 609 A client that has received multiple partial responses to GET requests 610 on a target resource MAY combine those responses into a larger 611 continuous range if they share the same strong validator. 613 If the most recent response is an incomplete 200 (OK) response, then 614 the header fields of that response are used for any combined response 615 and replace those of the matching stored responses. 617 If the most recent response is a 206 (Partial Content) response and 618 at least one of the matching stored responses is a 200 (OK), then the 619 combined response header fields consist of the most recent 200 620 response's header fields. If all of the matching stored responses 621 are 206 responses, then the stored response with the most recent 622 header fields is used as the source of header fields for the combined 623 response, except that the client MUST use other header fields 624 provided in the new response, aside from Content-Range, to replace 625 all instances of the corresponding header fields in the stored 626 response. 628 The combined response message body consists of the union of partial 629 content ranges in the new response and each of the selected 630 responses. If the union consists of the entire range of the 631 representation, then the client MUST process the combined response as 632 if it were a complete 200 (OK) response, including a Content-Length 633 header field that reflects the complete length. Otherwise, the 634 client MUST process the set of continuous ranges as one of the 635 following: an incomplete 200 (OK) response if the combined response 636 is a prefix of the representation, a single 206 (Partial Content) 637 response containing a multipart/byteranges body, or multiple 206 638 (Partial Content) responses, each with one continuous range that is 639 indicated by a Content-Range header field. 641 4.4. 416 Range Not Satisfiable 643 The 416 (Range Not Satisfiable) status code indicates that none of 644 the ranges in the request's Range header field (Section 3.1) overlap 645 the current extent of the selected resource or that the set of ranges 646 requested has been rejected due to invalid ranges or an excessive 647 request of small or overlapping ranges. 649 For byte ranges, failing to overlap the current extent means that the 650 first-byte-pos of all of the byte-range-spec values were greater than 651 the current length of the selected representation. When this status 652 code is generated in response to a byte-range request, the sender 653 SHOULD generate a Content-Range header field specifying the current 654 length of the selected representation (Section 4.2). 656 For example: 658 HTTP/1.1 416 Range Not Satisfiable 659 Date: Fri, 20 Jan 2012 15:41:54 GMT 660 Content-Range: bytes */47022 662 Note: Because servers are free to ignore Range, many 663 implementations will simply respond with the entire selected 664 representation in a 200 (OK) response. That is partly because 665 most clients are prepared to receive a 200 (OK) to complete the 666 task (albeit less efficiently) and partly because clients might 667 not stop making an invalid partial request until they have 668 received a complete representation. Thus, clients cannot depend 669 on receiving a 416 (Range Not Satisfiable) response even when it 670 is most appropriate. 672 5. IANA Considerations 674 5.1. Range Unit Registry 676 The "HTTP Range Unit Registry" defines the namespace for the range 677 unit names and refers to their corresponding specifications. The 678 registry has been created and is now maintained at 679 . 681 5.1.1. Procedure 683 Registration of an HTTP Range Unit MUST include the following fields: 685 o Name 687 o Description 689 o Pointer to specification text 691 Values to be added to this namespace require IETF Review (see 692 [RFC5226], Section 4.1). 694 5.1.2. Registrations 696 The initial range unit registry contains the registrations below: 698 +-------------+-----------------------------------------+-----------+ 699 | Range Unit | Description | Reference | 700 | Name | | | 701 +-------------+-----------------------------------------+-----------+ 702 | bytes | a range of octets | Section 2 | 703 | | | .1 | 704 | none | reserved as keyword, indicating no | Section 2 | 705 | | ranges are supported | .3 | 706 +-------------+-----------------------------------------+-----------+ 708 The change controller is: "IETF (iesg@ietf.org) - Internet 709 Engineering Task Force". 711 5.2. Status Code Registration 713 The "Hypertext Transfer Protocol (HTTP) Status Code Registry" located 714 at has been 715 updated to include the registrations below: 717 +-------+-----------------------+--------------+ 718 | Value | Description | Reference | 719 +-------+-----------------------+--------------+ 720 | 206 | Partial Content | Section 4.1 | 721 | 416 | Range Not Satisfiable | Section 4.4 | 722 +-------+-----------------------+--------------+ 724 5.3. Header Field Registration 726 HTTP header fields are registered within the "Message Headers" 727 registry maintained at . 730 This document defines the following HTTP header fields, so their 731 associated registry entries have been updated according to the 732 permanent registrations below (see [BCP90]): 734 +-------------------+----------+----------+--------------+ 735 | Header Field Name | Protocol | Status | Reference | 736 +-------------------+----------+----------+--------------+ 737 | Accept-Ranges | http | standard | Section 2.3 | 738 | Content-Range | http | standard | Section 4.2 | 739 | If-Range | http | standard | Section 3.2 | 740 | Range | http | standard | Section 3.1 | 741 +-------------------+----------+----------+--------------+ 743 The change controller is: "IETF (iesg@ietf.org) - Internet 744 Engineering Task Force". 746 5.4. Internet Media Type Registration 748 IANA maintains the registry of Internet media types [BCP13] at 749 . 751 This document serves as the specification for the Internet media type 752 "multipart/byteranges". The following has been registered with IANA. 754 5.4.1. Internet Media Type multipart/byteranges 756 Type name: multipart 758 Subtype name: byteranges 759 Required parameters: boundary 761 Optional parameters: N/A 763 Encoding considerations: only "7bit", "8bit", or "binary" are 764 permitted 766 Security considerations: see Section 6 768 Interoperability considerations: N/A 770 Published specification: This specification (see Appendix A). 772 Applications that use this media type: HTTP components supporting 773 multiple ranges in a single request. 775 Fragment identifier considerations: N/A 777 Additional information: 779 Deprecated alias names for this type: N/A 781 Magic number(s): N/A 783 File extension(s): N/A 785 Macintosh file type code(s): N/A 787 Person and email address to contact for further information: See Aut 788 hors' Addresses section. 790 Intended usage: COMMON 792 Restrictions on usage: N/A 794 Author: See Authors' Addresses section. 796 Change controller: IESG 798 6. Security Considerations 800 This section is meant to inform developers, information providers, 801 and users of known security concerns specific to the HTTP range 802 request mechanisms. More general security considerations are 803 addressed in HTTP messaging [MESSGNG] and semantics [SEMNTCS]. 805 6.1. Denial-of-Service Attacks Using Range 807 Unconstrained multiple range requests are susceptible to denial-of- 808 service attacks because the effort required to request many 809 overlapping ranges of the same data is tiny compared to the time, 810 memory, and bandwidth consumed by attempting to serve the requested 811 data in many parts. Servers ought to ignore, coalesce, or reject 812 egregious range requests, such as requests for more than two 813 overlapping ranges or for many small ranges in a single set, 814 particularly when the ranges are requested out of order for no 815 apparent reason. Multipart range requests are not designed to 816 support random access. 818 7. References 820 7.1. Normative References 822 [CACHING] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 823 Ed., "Hypertext Transfer Protocol (HTTP): Caching", draft- 824 ietf-httpbis-cache-00 (work in progress), April 2018. 826 [CONDTNL] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 827 Ed., "Hypertext Transfer Protocol (HTTP): Conditional 828 Requests", draft-ietf-httpbis-conditional-00 (work in 829 progress), April 2018. 831 [MESSGNG] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 832 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message 833 Syntax and Routing", draft-ietf-httpbis-messaging-00 (work 834 in progress), April 2018. 836 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 837 Extensions (MIME) Part Two: Media Types", RFC 2046, 838 DOI 10.17487/RFC2046, November 1996, 839 . 841 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 842 Requirement Levels", BCP 14, RFC 2119, 843 DOI 10.17487/RFC2119, March 1997, 844 . 846 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 847 Specifications: ABNF", STD 68, RFC 5234, 848 DOI 10.17487/RFC5234, January 2008, 849 . 851 [SEMNTCS] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 852 Ed., "Hypertext Transfer Protocol (HTTP): Semantics and 853 Content", draft-ietf-httpbis-semantics-00 (work in 854 progress), April 2018. 856 7.2. Informative References 858 [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type 859 Specifications and Registration Procedures", BCP 13, 860 RFC 6838, January 2013, 861 . 863 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration 864 Procedures for Message Header Fields", BCP 90, RFC 3864, 865 September 2004, . 867 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 868 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 869 DOI 10.17487/RFC5226, May 2008, 870 . 872 [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 873 "Hypertext Transfer Protocol (HTTP): Range Requests", 874 RFC 7233, DOI 10.17487/RFC7233, June 2014, 875 . 877 Appendix A. Internet Media Type multipart/byteranges 879 When a 206 (Partial Content) response message includes the content of 880 multiple ranges, they are transmitted as body parts in a multipart 881 message body ([RFC2046], Section 5.1) with the media type of 882 "multipart/byteranges". 884 The multipart/byteranges media type includes one or more body parts, 885 each with its own Content-Type and Content-Range fields. The 886 required boundary parameter specifies the boundary string used to 887 separate each body part. 889 Implementation Notes: 891 1. Additional CRLFs might precede the first boundary string in the 892 body. 894 2. Although [RFC2046] permits the boundary string to be quoted, some 895 existing implementations handle a quoted boundary string 896 incorrectly. 898 3. A number of clients and servers were coded to an early draft of 899 the byteranges specification that used a media type of multipart/ 900 x-byteranges, which is almost (but not quite) compatible with 901 this type. 903 Despite the name, the "multipart/byteranges" media type is not 904 limited to byte ranges. The following example uses an "exampleunit" 905 range unit: 907 HTTP/1.1 206 Partial Content 908 Date: Tue, 14 Nov 1995 06:25:24 GMT 909 Last-Modified: Tue, 14 July 04:58:08 GMT 910 Content-Length: 2331785 911 Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES 913 --THIS_STRING_SEPARATES 914 Content-Type: video/example 915 Content-Range: exampleunit 1.2-4.3/25 917 ...the first range... 918 --THIS_STRING_SEPARATES 919 Content-Type: video/example 920 Content-Range: exampleunit 11.2-14.3/25 922 ...the second range 923 --THIS_STRING_SEPARATES-- 925 Appendix B. Changes from RFC 7233 927 None yet. 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 [MESSGNG]: 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 954 Section 1.2 of [MESSGNG]. 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 1007 This section is to be removed before publishing as an RFC. 1009 E.1. Since RFC 7233 1011 The changes in this draft are purely editorial: 1013 o Change boilerplate and abstract to indicate the "draft" status, 1014 and update references to ancestor specifications. 1016 o Remove version "1.1" from document title, indicating that this 1017 specification applies to all HTTP versions. 1019 o Adjust historical notes. 1021 o Update links to sibling specifications. 1023 o Replace sections listing changes from RFC 2616 by new empty 1024 sections referring to RFC 723x. 1026 o Remove acknowledgements specific to RFC 723x. 1028 o Move "Acknowledgements" to the very end and make them unnumbered. 1030 Index 1032 2 1033 206 Partial Content (status code) 9 1035 4 1036 416 Range Not Satisfiable (status code) 14 1038 A 1039 Accept-Ranges header field 6 1041 C 1042 Content-Range header field 11 1044 G 1045 Grammar 1046 Accept-Ranges 6 1047 acceptable-ranges 6 1048 byte-content-range 12 1049 byte-range 12 1050 byte-range-resp 12 1051 byte-range-set 5 1052 byte-range-spec 5 1053 byte-ranges-specifier 5 1054 bytes-unit 4 1055 complete-length 12 1056 Content-Range 12 1057 first-byte-pos 5 1058 If-Range 8 1059 last-byte-pos 5 1060 other-content-range 12 1061 other-range-resp 12 1062 other-range-unit 4, 6 1063 Range 7 1064 range-unit 4 1065 ranges-specifier 5 1066 suffix-byte-range-spec 5 1067 suffix-length 5 1068 unsatisfied-range 12 1070 I 1071 If-Range header field 8 1073 M 1074 Media Type 1075 multipart/byteranges 16, 20 1076 multipart/x-byteranges 20 1077 multipart/byteranges Media Type 16, 20 1078 multipart/x-byteranges Media Type 20 1080 R 1081 Range header field 7 1083 Acknowledgments 1085 See Appendix "Acknowledgments" of [MESSGNG]. 1087 Authors' Addresses 1089 Roy T. Fielding (editor) 1090 Adobe 1091 345 Park Ave 1092 San Jose, CA 95110 1093 USA 1095 EMail: fielding@gbiv.com 1096 URI: http://roy.gbiv.com/ 1097 Mark Nottingham (editor) 1098 Fastly 1100 EMail: mnot@mnot.net 1101 URI: https://www.mnot.net/ 1103 Julian F. Reschke (editor) 1104 greenbytes GmbH 1105 Hafenweg 16 1106 Muenster, NW 48155 1107 Germany 1109 EMail: julian.reschke@greenbytes.de 1110 URI: http://greenbytes.de/tech/webdav/