idnits 2.17.1 draft-ietf-httpbis-p5-range-22.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 23, 2013) is 4080 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) == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-22 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-22 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-22 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-22 -- 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 (~~), 5 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 27, 2013 J. Reschke, Ed. 7 greenbytes 8 February 23, 2013 10 Hypertext Transfer Protocol (HTTP/1.1): Range Requests 11 draft-ietf-httpbis-p5-range-22 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.3. 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 27, 2013. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 This document may contain material from IETF Documents or IETF 66 Contributions published or made publicly available before November 67 10, 2008. The person(s) controlling the copyright in some of this 68 material may not have granted the IETF Trust the right to allow 69 modifications of such material outside the IETF Standards Process. 70 Without obtaining an adequate license from the person(s) controlling 71 the copyright in such materials, this document may not be modified 72 outside the IETF Standards Process, and derivative works of it may 73 not be created outside the IETF Standards Process, except to format 74 it for publication as an RFC or to translate it into languages other 75 than English. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4 81 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 82 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 4 83 2.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . . . 5 84 2.2. Other Range Units . . . . . . . . . . . . . . . . . . . . 7 85 2.3. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7 86 3. Range Requests . . . . . . . . . . . . . . . . . . . . . . . . 7 87 3.1. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 7 88 3.2. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 9 89 4. Responses to a Range Request . . . . . . . . . . . . . . . . . 9 90 4.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 10 91 4.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 12 92 4.3. Combining Ranges . . . . . . . . . . . . . . . . . . . . . 14 93 4.4. 416 Range Not Satisfiable . . . . . . . . . . . . . . . . 15 94 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 95 5.1. Range Unit Registry . . . . . . . . . . . . . . . . . . . 15 96 5.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 15 97 5.1.2. Registrations . . . . . . . . . . . . . . . . . . . . 16 98 5.2. Status Code Registration . . . . . . . . . . . . . . . . . 16 99 5.3. Header Field Registration . . . . . . . . . . . . . . . . 16 100 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 101 6.1. Denial of Service Attacks using Range . . . . . . . . . . 17 102 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 103 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 104 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 105 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 106 Appendix A. Internet Media Type multipart/byteranges . . . . . . 18 107 Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 20 108 Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 21 109 Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 21 110 Appendix E. Change Log (to be removed by RFC Editor before 111 publication) . . . . . . . . . . . . . . . . . . . . 23 112 E.1. Since draft-ietf-httpbis-p5-range-19 . . . . . . . . . . . 23 113 E.2. Since draft-ietf-httpbis-p5-range-20 . . . . . . . . . . . 23 114 E.3. Since draft-ietf-httpbis-p5-range-21 . . . . . . . . . . . 23 115 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, obsoleting those parts 131 previously defined in [RFC2616]. 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 the list rule extension defined in Section 156 1.2 of [Part1]. Appendix C describes rules imported from other 157 documents. Appendix D shows the collected ABNF with the list rule 158 expanded. 160 2. Range Units 162 A representation can be partitioned into subranges according to 163 various structural units, depending on the structure inherent in the 164 representation's media type. This "range unit" is used in the 165 Accept-Ranges (Section 2.3) response header field to advertise 166 support for range requests, the Range (Section 3.1) request header 167 field to delineate the parts of a representation that are requested, 168 and the Content-Range (Section 4.2) payload header field to describe 169 which part of a representation is being transferred. 171 range-unit = bytes-unit / other-range-unit 173 2.1. Byte Ranges 175 Since representation data is transferred in payloads as a sequence of 176 octets, a byte range is a meaningful substructure for any 177 representation transferable over HTTP (Section 3 of [Part2]). We 178 define the "bytes" range unit for expressing subranges of the data's 179 octet sequence. 181 bytes-unit = "bytes" 183 A byte range operation MAY specify a single range of bytes, or a set 184 of ranges within a single representation. 186 byte-ranges-specifier = bytes-unit "=" byte-range-set 187 byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec ) 188 byte-range-spec = first-byte-pos "-" [ last-byte-pos ] 189 first-byte-pos = 1*DIGIT 190 last-byte-pos = 1*DIGIT 192 The first-byte-pos value in a byte-range-spec gives the byte-offset 193 of the first byte in a range. The last-byte-pos value gives the 194 byte-offset of the last byte in the range; that is, the byte 195 positions specified are inclusive. Byte offsets start at zero. 197 Examples of byte-ranges-specifier values: 199 o The first 500 bytes (byte offsets 0-499, inclusive): 201 bytes=0-499 203 o The second 500 bytes (byte offsets 500-999, inclusive): 205 bytes=500-999 207 A byte-range-spec is invalid if the last-byte-pos value is present 208 and less than the first-byte-pos. 210 A client can limit the number of bytes requested without knowing the 211 size of the selected representation. If the last-byte-pos value is 212 absent, or if the value is greater than or equal to the current 213 length of the representation data, the byte range is interpreted as 214 the remainder of the representation (i.e., the server replaces the 215 value of last-byte-pos with a value that is one less than the current 216 length of the selected representation). 218 A client can request the last N bytes of the selected representation 219 using a suffix-byte-range-spec. 221 suffix-byte-range-spec = "-" suffix-length 222 suffix-length = 1*DIGIT 224 If the selected representation is shorter than the specified suffix- 225 length, the entire representation is used. For example (assuming a 226 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 ought to 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 Origin servers that support byte-range requests MAY send 275 Accept-Ranges: bytes 277 but are not required to do so. Clients MAY generate range requests 278 without having received this header field for the resource involved. 279 Range units are defined in Section 2. 281 Servers that do not support any kind of range request for the target 282 resource resource MAY send 284 Accept-Ranges: none 286 to advise the client not to attempt a range request. 288 3. Range Requests 290 3.1. Range 292 The "Range" header field on a GET request modifies the method 293 semantics to request transfer of only one or more subranges of the 294 selected representation data, rather than the entire selected 295 representation data. 297 Range = byte-ranges-specifier / other-ranges-specifier 298 other-ranges-specifier = other-range-unit "=" other-range-set 299 other-range-set = 1*CHAR 301 A server MAY ignore the Range header field. However, origin servers 302 and intermediate caches ought to support byte ranges when possible, 303 since Range supports efficient recovery from partially failed 304 transfers and partial retrieval of large representations. A server 305 MUST ignore a Range header field received with a request method other 306 than GET. 308 An origin server MUST ignore a Range header field that contains a 309 range unit it does not understand. A proxy MAY either discard a 310 Range header field that contains a range unit it does not understand 311 or pass it to the next inbound server when forwarding the request. 313 A server that supports range requests ought to ignore or reject a 314 Range header field that consists of more than two overlapping ranges, 315 or a 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 331 preconditions of [Part4] and only if the result of their evaluation 332 is leading toward a 200 (OK) response. In other words, Range is 333 ignored when a conditional GET would result in a 304 (Not Modified) 334 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 condition fails 357 because the representation has been modified, the client would then 358 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 Clients MUST NOT use an entity-tag marked as weak in an If-Range 369 field value and MUST NOT use a Last-Modified date in an If-Range 370 field value unless it has no entity-tag for the representation and 371 the Last-Modified date it does have for the representation is strong 372 in the sense defined by Section 2.2.2 of [Part4]. 374 A server that evaluates a conditional range request that is 375 applicable to one of its representations MUST evaluate the condition 376 as false if the entity-tag used as a validator is marked as weak or, 377 when an HTTP-date is used as the validator, if the date value is not 378 strong in the sense defined by Section 2.2.2 of [Part4]. (A server 379 can distinguish between a valid HTTP-date and any form of entity-tag 380 by examining the first two characters.) 382 A client MUST NOT generate an If-Range header field in a request that 383 does not contain a Range header field. A server MUST ignore an If- 384 Range header field received in a request that does not contain a 385 Range header field. An origin server MUST ignore an If-Range header 386 field received in a request for a target resource that does not 387 support Range requests. 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, then the server MUST 393 ignore 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 requests'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 block 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 ask for 470 multiple ranges in a single request. 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 unless otherwise indicated by explicit 497 cache controls (see Section 4.1.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, where "strong validator" is defined to be 594 either an entity-tag that is not marked as weak (Section 2.3 of 595 [Part4]) or, if no entity-tag is provided, a Last-Modified value that 596 is strong in the sense defined by Section 2.2.2 of [Part4]. 598 A client that has received multiple partial responses to GET requests 599 on a target resource MAY combine those responses into a larger 600 continuous range if they share the same strong validator. 602 If the most recent response is an incomplete 200 (OK) response, then 603 the header fields of that response are used for any combined response 604 and replace those of the matching stored responses. 606 If the most recent response is a 206 (Partial Content) response and 607 at least one of the matching stored responses is a 200 (OK), then the 608 combined response header fields consist of the most recent 200 609 response's header fields. If all of the matching stored responses 610 are 206 responses, then the stored response with the most recent 611 header fields is used as the source of header fields for the combined 612 response, except that the client MUST use other header fields 613 provided in the new response, aside from Content-Range, to replace 614 all instances of the corresponding header fields in the stored 615 response. 617 The combined response message body consists of the union of partial 618 content ranges in the new response and each of the selected 619 responses. If the union consists of the entire range of the 620 representation, then the client MUST record the combined response as 621 if it were a complete 200 (OK) response, including a Content-Length 622 header field that reflects the complete length. Otherwise, the 623 client MUST record the set of continuous ranges as one of the 624 following: an incomplete 200 (OK) response if the combined response 625 is a prefix of the representation, a single 206 (Partial Content) 626 response containing a multipart/byteranges body, or multiple 206 627 (Partial Content) responses, each with one continuous range that is 628 indicated by a Content-Range header field. 630 4.4. 416 Range Not Satisfiable 632 The 416 (Range Not Satisfiable) status code indicates that none of 633 the ranges in the request's Range header field (Section 3.1) overlap 634 the current extent of the selected resource or that the set of ranges 635 requested has been rejected due to invalid ranges or an excessive 636 request of small or overlapping ranges. 638 For byte ranges, failing to overlap the current extent means that the 639 first-byte-pos of all of the byte-range-spec values were greater than 640 the current length of the selected representation. When this status 641 code is generated in response to a byte range request, the sender 642 SHOULD generate a Content-Range header field specifying the current 643 length of the selected representation (Section 4.2). 645 For example: 647 HTTP/1.1 416 Range Not Satisfiable 648 Date: Mon, 20 Jan 2012 15:41:54 GMT 649 Content-Range: bytes */47022 651 Note: Because servers are free to ignore Range, many 652 implementations will simply respond with 200 (OK) if the requested 653 ranges are invalid or not satisfiable. That is partly because 654 most clients are prepared to receive a 200 (OK) to complete the 655 task (albeit less efficiently) and partly because clients might 656 not stop making an invalid partial request until they have 657 received a complete representation. Thus, clients cannot depend 658 on receiving a 416 (Range Not Satisfiable) response even when it 659 is most appropriate. 661 5. IANA Considerations 663 5.1. Range Unit Registry 665 The HTTP Range Unit Registry defines the name space for the range 666 unit names and refers to their corresponding specifications. The 667 registry is maintained at 668 . 670 5.1.1. Procedure 672 Registration of an HTTP Range Unit MUST include the following fields: 674 o Name 676 o Description 678 o Pointer to specification text 680 Values to be added to this name space require IETF Review (see 681 [RFC5226], Section 4.1). 683 5.1.2. Registrations 685 The initial HTTP Range Unit Registry shall contain the registrations 686 below: 688 +-------------+---------------------------------------+-------------+ 689 | Range Unit | Description | Reference | 690 | Name | | | 691 +-------------+---------------------------------------+-------------+ 692 | bytes | a range of octets | Section 2.1 | 693 | none | reserved as keyword, indicating no | Section 2.3 | 694 | | ranges are supported | | 695 +-------------+---------------------------------------+-------------+ 697 The change controller is: "IETF (iesg@ietf.org) - Internet 698 Engineering Task Force". 700 5.2. Status Code Registration 702 The HTTP Status Code Registry located at 703 shall be updated 704 with the registrations below: 706 +-------+-----------------------+-------------+ 707 | Value | Description | Reference | 708 +-------+-----------------------+-------------+ 709 | 206 | Partial Content | Section 4.1 | 710 | 416 | Range Not Satisfiable | Section 4.4 | 711 +-------+-----------------------+-------------+ 713 5.3. Header Field Registration 715 The Message Header Field Registry located at shall be 717 updated with the 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 6. Security Considerations 733 This section is meant to inform developers, information providers, 734 and users of known security concerns specific to the HTTP/1.1 range 735 request mechanisms. More general security considerations are 736 addressed in HTTP messaging [Part1] and semantics [Part2]. 738 6.1. Denial of Service Attacks using Range 740 Unconstrained multiple range requests are susceptible to denial of 741 service attacks because the effort required to request many 742 overlapping ranges of the same data is tiny compared to the time, 743 memory, and bandwidth consumed by attempting to serve the requested 744 data in many parts. Servers ought to ignore, coalesce, or reject 745 egregious range requests, such as requests for more than two 746 overlapping ranges or for many small ranges in a single set, 747 particularly when the ranges are requested out of order for no 748 apparent reason. Multipart range requests are not designed to 749 support random access. 751 7. Acknowledgments 753 See Section 9 of [Part1]. 755 8. References 757 8.1. Normative References 759 [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 760 Protocol (HTTP/1.1): Message Syntax and Routing", 761 draft-ietf-httpbis-p1-messaging-22 (work in progress), 762 February 2013. 764 [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 765 Protocol (HTTP/1.1): Semantics and Content", 766 draft-ietf-httpbis-p2-semantics-22 (work in progress), 767 February 2013. 769 [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 770 Protocol (HTTP/1.1): Conditional Requests", 771 draft-ietf-httpbis-p4-conditional-22 (work in progress), 772 February 2013. 774 [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 775 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 776 draft-ietf-httpbis-p6-cache-22 (work in progress), 777 February 2013. 779 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 780 Extensions (MIME) Part Two: Media Types", RFC 2046, 781 November 1996. 783 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 784 Requirement Levels", BCP 14, RFC 2119, March 1997. 786 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 787 Specifications: ABNF", STD 68, RFC 5234, January 2008. 789 8.2. Informative References 791 [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type 792 Specifications and Registration Procedures", BCP 13, 793 RFC 6838, January 2013. 795 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration 796 Procedures for Message Header Fields", BCP 90, RFC 3864, 797 September 2004. 799 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 800 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 801 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 803 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 804 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 805 May 2008. 807 Appendix A. Internet Media Type multipart/byteranges 809 When a 206 (Partial Content) response message includes the content of 810 multiple ranges, they are transmitted as body parts in a multipart 811 message body ([RFC2046], Section 5.1) with the media type of 812 "multipart/byteranges". The following definition is to be registered 813 with IANA [BCP13]. 815 The multipart/byteranges media type includes one or more body parts, 816 each with its own Content-Type and Content-Range fields. The 817 required boundary parameter specifies the boundary string used to 818 separate each body part. 820 Type name: multipart 822 Subtype name: byteranges 824 Required parameters: boundary 826 Optional parameters: none 828 Encoding considerations: only "7bit", "8bit", or "binary" are 829 permitted 831 Security considerations: none 833 Interoperability considerations: none 835 Published specification: This specification (see Appendix A). 837 Applications that use this media type: HTTP components supporting 838 multiple ranges in a single request. 840 Additional information: 842 Magic number(s): none 844 File extension(s): none 846 Macintosh file type code(s): none 848 Person and email address to contact for further information: See 849 Authors Section. 851 Intended usage: COMMON 853 Restrictions on usage: none 855 Author/Change controller: IESG 857 Implementation Notes: 859 1. Additional CRLFs might precede the first boundary string in the 860 body. 862 2. Although [RFC2046] permits the boundary string to be quoted, some 863 existing implementations handle a quoted boundary string 864 incorrectly. 866 3. A number of clients and servers were coded to an early draft of 867 the byteranges specification that used a media type of multipart/ 868 x-byteranges, which is almost (but not quite) compatible with 869 this type. 871 Despite the name, the "multipart/byteranges" media type is not 872 limited to byte ranges. The following example uses an "exampleunit" 873 range unit: 875 HTTP/1.1 206 Partial Content 876 Date: Tue, 14 Nov 1995 06:25:24 GMT 877 Last-Modified: Tue, 14 July 04:58:08 GMT 878 Content-Length: 2331785 879 Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES 881 --THIS_STRING_SEPARATES 882 Content-Type: video/example 883 Content-Range: exampleunit 1.2-4.3/25 885 ...the first range... 886 --THIS_STRING_SEPARATES 887 Content-Type: video/example 888 Content-Range: exampleunit 11.2-14.3/25 890 ...the second range 891 --THIS_STRING_SEPARATES-- 893 Appendix B. Changes from RFC 2616 895 A weak validator cannot be used in a 206 response. (Section 4.1) 897 The Content-Range header field only has meaning when the status code 898 explicitly defines its use. (Section 4.2) 900 Servers are given more leeway in how they respond to a range request, 901 in order to mitigate abuse by malicious (or just greedy) clients. 903 multipart/byteranges can consist of a single part. (Appendix A) 905 This specification introduces a Range Unit Registry. (Section 5.1) 907 Appendix C. Imported ABNF 909 The following core rules are included by reference, as defined in 910 Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), 911 CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double 912 quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 913 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII 914 character). 916 Note that all rules derived from token are to be compared case- 917 insensitively, like range-unit and acceptable-ranges. 919 The rules below are defined in [Part1]: 921 OWS = 922 token = 924 The rules below are defined in other parts: 926 HTTP-date = 927 entity-tag = 929 Appendix D. Collected ABNF 930 Accept-Ranges = acceptable-ranges 932 Content-Range = byte-content-range / other-content-range 934 HTTP-date = 936 If-Range = entity-tag / HTTP-date 938 OWS = 940 Range = byte-ranges-specifier / other-ranges-specifier 942 acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS 943 range-unit ] ) ) / "none" 945 byte-content-range = bytes-unit SP ( byte-range-resp / 946 unsatisfied-range ) 947 byte-range = first-byte-pos "-" last-byte-pos 948 byte-range-resp = byte-range "/" ( complete-length / "*" ) 949 byte-range-set = *( "," OWS ) ( byte-range-spec / 950 suffix-byte-range-spec ) *( OWS "," [ OWS ( byte-range-spec / 951 suffix-byte-range-spec ) ] ) 952 byte-range-spec = first-byte-pos "-" [ last-byte-pos ] 953 byte-ranges-specifier = bytes-unit "=" byte-range-set 954 bytes-unit = "bytes" 956 complete-length = 1*DIGIT 958 entity-tag = 960 first-byte-pos = 1*DIGIT 962 last-byte-pos = 1*DIGIT 964 other-content-range = other-range-unit SP other-range-resp 965 other-range-resp = *CHAR 966 other-range-set = 1*CHAR 967 other-range-unit = token 968 other-ranges-specifier = other-range-unit "=" other-range-set 970 range-unit = bytes-unit / other-range-unit 972 suffix-byte-range-spec = "-" suffix-length 973 suffix-length = 1*DIGIT 975 token = 977 unsatisfied-range = "*/" complete-length 979 Appendix E. Change Log (to be removed by RFC Editor before publication) 981 Changes up to the first Working Group Last Call draft are summarized 982 in . 985 E.1. Since draft-ietf-httpbis-p5-range-19 987 Closed issues: 989 o : "ABNF list 990 expansion code problem" 992 o : "ABNF 993 requirements for recipients" 995 o : "reserve 996 'none' as byte range unit" 998 o : "note 999 introduction of new IANA registries as normative changes" 1001 o : "range units 1002 vs leading zeroes vs size" 1004 E.2. Since draft-ietf-httpbis-p5-range-20 1006 o Conformance criteria and considerations regarding error handling 1007 are now defined in Part 1. 1009 E.3. Since draft-ietf-httpbis-p5-range-21 1011 Closed issues: 1013 o : "Security 1014 consideration: range flooding" 1016 o : "Allowing 1017 heuristic caching for new status codes" 1019 o : "Add 1020 limitations to Range to reduce its use as a denial-of-service 1021 tool" 1023 Index 1025 2 1026 206 Partial Content (status code) 10 1028 4 1029 416 Range Not Satisfiable (status code) 15 1031 A 1032 Accept-Ranges header field 7 1034 C 1035 Content-Range header field 12 1037 G 1038 Grammar 1039 Accept-Ranges 7 1040 acceptable-ranges 7 1041 byte-content-range 12 1042 byte-range 12 1043 byte-range-resp 12 1044 byte-range-set 5 1045 byte-range-spec 5 1046 byte-ranges-specifier 5 1047 bytes-unit 5 1048 complete-length 12 1049 Content-Range 12 1050 first-byte-pos 5 1051 If-Range 9 1052 last-byte-pos 5 1053 other-content-range 12 1054 other-range-resp 12 1055 other-range-unit 5, 7 1056 Range 7 1057 range-unit 5 1058 ranges-specifier 5 1059 suffix-byte-range-spec 6 1060 suffix-length 6 1061 unsatisfied-range 12 1063 I 1064 If-Range header field 9 1066 M 1067 Media Type 1068 multipart/byteranges 18 1069 multipart/x-byteranges 20 1070 multipart/byteranges Media Type 18 1071 multipart/x-byteranges Media Type 20 1073 R 1074 Range header field 7 1076 Authors' Addresses 1078 Roy T. Fielding (editor) 1079 Adobe Systems Incorporated 1080 345 Park Ave 1081 San Jose, CA 95110 1082 USA 1084 EMail: fielding@gbiv.com 1085 URI: http://roy.gbiv.com/ 1087 Yves Lafon (editor) 1088 World Wide Web Consortium 1089 W3C / ERCIM 1090 2004, rte des Lucioles 1091 Sophia-Antipolis, AM 06902 1092 France 1094 EMail: ylafon@w3.org 1095 URI: http://www.raubacapeu.net/people/yves/ 1097 Julian F. Reschke (editor) 1098 greenbytes GmbH 1099 Hafenweg 16 1100 Muenster, NW 48155 1101 Germany 1103 EMail: julian.reschke@greenbytes.de 1104 URI: http://greenbytes.de/tech/webdav/