idnits 2.17.1 draft-ietf-httpbis-p5-range-23.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 (July 15, 2013) is 3937 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 806, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-23 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-23 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-23 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-23 -- 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: January 16, 2014 J. Reschke, Ed. 7 greenbytes 8 July 15, 2013 10 Hypertext Transfer Protocol (HTTP/1.1): Range Requests 11 draft-ietf-httpbis-p5-range-23 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.4. 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 January 16, 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 . . . . . . . . . . . . . . . . . 10 90 4.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 10 91 4.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 12 92 4.3. Combining Ranges . . . . . . . . . . . . . . . . . . . . . 14 93 4.4. 416 Range Not Satisfiable . . . . . . . . . . . . . . . . 15 94 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 95 5.1. Range Unit Registry . . . . . . . . . . . . . . . . . . . 15 96 5.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 15 97 5.1.2. Registrations . . . . . . . . . . . . . . . . . . . . 16 98 5.2. Status Code Registration . . . . . . . . . . . . . . . . . 16 99 5.3. Header Field Registration . . . . . . . . . . . . . . . . 16 100 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 101 6.1. Denial of Service Attacks using Range . . . . . . . . . . 17 102 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 103 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 104 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 105 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 106 Appendix A. Internet Media Type multipart/byteranges . . . . . . 18 107 Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 20 108 Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 21 109 Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 21 110 Appendix E. Change Log (to be removed by RFC Editor before 111 publication) . . . . . . . . . . . . . . . . . . . . 23 112 E.1. Since draft-ietf-httpbis-p5-range-19 . . . . . . . . . . . 23 113 E.2. Since draft-ietf-httpbis-p5-range-20 . . . . . . . . . . . 23 114 E.3. Since draft-ietf-httpbis-p5-range-21 . . . . . . . . . . . 23 115 E.4. Since draft-ietf-httpbis-p5-range-22 . . . . . . . . . . . 24 116 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 118 1. Introduction 120 Hypertext Transfer Protocol (HTTP) clients often encounter 121 interrupted data transfers as a result of canceled requests or 122 dropped connections. When a client has stored a partial 123 representation, it is desirable to request the remainder of that 124 representation in a subsequent request rather than transfer the 125 entire representation. Likewise, devices with limited local storage 126 might benefit from being able to request only a subset of a larger 127 representation, such as a single page of a very large document, or 128 the dimensions of an embedded image. 130 This document defines HTTP/1.1 range requests, partial responses, and 131 the multipart/byteranges media type. Range requests are an OPTIONAL 132 feature of HTTP, designed so that recipients not implementing this 133 feature (or not supporting it for the target resource) can respond as 134 if it is a normal GET request without impacting interoperability. 135 Partial responses are indicated by a distinct status code to not be 136 mistaken for full responses by caches that might not implement the 137 feature. 139 Although the range request mechanism is designed to allow for 140 extensible range types, this specification only defines requests for 141 byte ranges. 143 1.1. Conformance and Error Handling 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 Conformance criteria and considerations regarding error handling are 150 defined in Section 2.5 of [Part1]. 152 1.2. Syntax Notation 154 This specification uses the Augmented Backus-Naur Form (ABNF) 155 notation of [RFC5234] with 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 request can specify a single range of bytes, or a set of 184 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. 227 Additional examples, assuming a representation of length 10000: 229 o The final 500 bytes (byte offsets 9500-9999, inclusive): 231 bytes=-500 233 Or: 235 bytes=9500- 237 o The first and last bytes only (bytes 0 and 9999): 239 bytes=0-0,-1 241 o Other valid (but not canonical) specifications of the second 500 242 bytes (byte offsets 500-999, inclusive): 244 bytes=500-600,601-999 245 bytes=500-700,601-999 247 If a valid byte-range-set includes at least one byte-range-spec with 248 a first-byte-pos that is less than the current length of the 249 representation, or at least one suffix-byte-range-spec with a non- 250 zero suffix-length, then the byte-range-set is satisfiable. 251 Otherwise, the byte-range-set is unsatisfiable. 253 In the byte range syntax, first-byte-pos, last-byte-pos, and suffix- 254 length are expressed as decimal number of octets. Since there is no 255 predefined limit to the length of a payload, recipients ought to 256 anticipate potentially large decimal numerals and prevent parsing 257 errors due to integer conversion overflows. 259 2.2. Other Range Units 261 Range units are intended to be extensible. New range units ought to 262 be registered with IANA, as defined in Section 5.1. 264 other-range-unit = token 266 2.3. Accept-Ranges 268 The "Accept-Ranges" header field allows a server to indicate that it 269 supports range requests for the target resource. 271 Accept-Ranges = acceptable-ranges 272 acceptable-ranges = 1#range-unit / "none" 274 Origin servers that support byte-range requests MAY send 276 Accept-Ranges: bytes 278 but are not required to do so. Clients MAY generate range requests 279 without having received this header field for the resource involved. 280 Range units are defined in Section 2. 282 Servers that do not support any kind of range request for the target 283 resource 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 either discard a 311 Range header field that contains a range unit it does not understand 312 or pass it to the next inbound server when forwarding the request. 314 A server that supports range requests ought to ignore or reject a 315 Range header field that consists of more than two overlapping ranges, 316 or a set of many small ranges that are not listed in ascending order, 317 since both are indications of either a broken client or a deliberate 318 denial of service attack (Section 6.1). A client SHOULD NOT request 319 multiple ranges that are inherently less efficient to process and 320 transfer than a single range that encompasses the same data. 322 A client that is requesting multiple ranges SHOULD list those ranges 323 in ascending order (the order in which they would typically be 324 received in a complete representation) unless there is a specific 325 need to request a later part earlier. For example, a user agent 326 processing a large representation with an internal catalog of parts 327 might need to request later parts first, particularly if the 328 representation consists of pages stored in reverse order and the user 329 agent wishes to transfer one page at a time. 331 The Range header field is evaluated after evaluating the precondition 332 header fields defined in [Part4], and only if the result in absence 333 of the Range header field would be a 200 (OK) response. In other 334 words, Range is ignored when a conditional GET would result in a 304 335 (Not Modified) response. 337 The If-Range header field (Section 3.2) can be used as a precondition 338 to applying the Range header field. 340 If all of the preconditions are true, the server supports the Range 341 header field for the target resource, and the specified range(s) are 342 valid and satisfiable (as defined in Section 2.1), the server SHOULD 343 send a 206 (Partial Content) response with a payload containing one 344 or more partial representations that correspond to the satisfiable 345 ranges requested, as defined in Section 4. 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 invalid or unsatisfiable, the server SHOULD send a 416 (Range Not 350 Satisfiable) response. 352 3.2. If-Range 354 If a client has a partial copy of a representation and wishes to have 355 an up-to-date copy of the entire representation, it could use the 356 Range header field with a conditional GET (using either or both of 357 If-Unmodified-Since and If-Match.) However, if the condition fails 358 because the representation has been modified, the client would then 359 have to make a second request to obtain the entire current 360 representation. 362 The "If-Range" header field allows a client to "short-circuit" the 363 second request. Informally, its meaning is: if the representation is 364 unchanged, send me the part(s) that I am requesting in Range; 365 otherwise, send me the entire representation. 367 If-Range = entity-tag / HTTP-date 369 A client MUST NOT generate an If-Range header field containing an 370 entity-tag that is marked as weak. A client MUST NOT generate an If- 371 Range header field containing a Last-Modified date unless the client 372 has no entity-tag for the corresponding representation and the Last- 373 Modified date is strong in the sense defined by Section 2.2.2 of 374 [Part4]. 376 A server that evaluates a conditional range request that is 377 applicable to one of its representations MUST evaluate the condition 378 as false if the entity-tag used as a validator is marked as weak or, 379 when an HTTP-date is used as the validator, if the date value is not 380 strong in the sense defined by Section 2.2.2 of [Part4]. (A server 381 can distinguish between a valid HTTP-date and any form of entity-tag 382 by examining the first two characters.) 384 A client MUST NOT generate an If-Range header field in a request that 385 does not contain a Range header field. A server MUST ignore an If- 386 Range header field received in a request that does not contain a 387 Range header field. An origin server MUST ignore an If-Range header 388 field received in a request for a target resource that does not 389 support Range requests. 391 If the validator given in the If-Range header field matches the 392 current validator for the selected representation of the target 393 resource, then the server SHOULD process the Range header field as 394 requested. If the validator does not match, then the server MUST 395 ignore the Range header field. 397 4. Responses to a Range Request 399 4.1. 206 Partial Content 401 The 206 (Partial Content) status code indicates that the server is 402 successfully fulfilling a range request for the target resource by 403 transferring one or more parts of the selected representation that 404 correspond to the satisfiable ranges found in the request's Range 405 header field (Section 3.1). 407 If a single part is being transferred, the server generating the 206 408 response MUST generate a Content-Range header field, describing what 409 range of the selected representation is enclosed, and a payload 410 consisting of the range. For example: 412 HTTP/1.1 206 Partial Content 413 Date: Wed, 15 Nov 1995 06:25:24 GMT 414 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 415 Content-Range: bytes 21010-47021/47022 416 Content-Length: 26012 417 Content-Type: image/gif 419 ... 26012 bytes of partial image data ... 421 If multiple parts are being transferred, the server generating the 422 206 response MUST generate a "multipart/byteranges" payload, as 423 defined in Appendix A, and a Content-Type header field containing the 424 multipart/byteranges media type and its required boundary parameter. 425 To avoid confusion with single part responses, a server MUST NOT 426 generate a Content-Range header field in the HTTP header block of a 427 multiple part response (this field will be sent in each part 428 instead). 430 Within the header area of each body part in the multipart payload, 431 the server MUST generate a Content-Range header field corresponding 432 to the range being enclosed in that body part. If the selected 433 representation would have had a Content-Type header field in a 200 434 (OK) response, the server SHOULD generate that same Content-Type 435 field in the header area of each body part. For example: 437 HTTP/1.1 206 Partial Content 438 Date: Wed, 15 Nov 1995 06:25:24 GMT 439 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 440 Content-Length: 1741 441 Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES 443 --THIS_STRING_SEPARATES 444 Content-Type: application/pdf 445 Content-Range: bytes 500-999/8000 447 ...the first range... 448 --THIS_STRING_SEPARATES 449 Content-Type: application/pdf 450 Content-Range: bytes 7000-7999/8000 452 ...the second range 453 --THIS_STRING_SEPARATES-- 455 When multiple ranges are requested, a server MAY coalesce any of the 456 ranges that overlap or that are separated by a gap that is smaller 457 than the overhead of sending multiple parts, regardless of the order 458 in which the corresponding byte-range-spec appeared in the received 459 Range header field. Since the typical overhead between parts of a 460 multipart/byteranges payload is around 80 bytes, depending on the 461 selected representation's media type and the chosen boundary 462 parameter length, it can be less efficient to transfer many small 463 disjoint parts than it is to transfer the entire selected 464 representation. 466 A server MUST NOT generate a multipart response to a request for a 467 single range, since a client that does not request multiple parts 468 might not support multipart responses. However, a server MAY 469 generate a multipart/byteranges payload with only a single body part 470 if multiple ranges were requested and only one range was found to be 471 satisfiable or only one range remained after coalescing. A client 472 that cannot process a multipart/byteranges response MUST NOT generate 473 a request that asks for multiple ranges. 475 When a multipart response payload is generated, the server SHOULD 476 send the parts in the same order that the corresponding byte-range- 477 spec appeared in the received Range header field, excluding those 478 ranges that were deemed unsatisfiable or that were coalesced into 479 other ranges. A client that receives a multipart response MUST 480 inspect the Content-Range header field present in each body part in 481 order to determine which range is contained in that body part; a 482 client cannot rely on receiving the same ranges that it requested, 483 nor the same order that it requested. 485 When a 206 response is generated, the server MUST generate the 486 following header fields, in addition to those required above, if the 487 field would have been sent in a 200 (OK) response to the same 488 request: Date, Cache-Control, ETag, Expires, Content-Location, and 489 Vary. 491 If a 206 is generated in response to a request with an If-Range 492 header field, the sender SHOULD NOT generate other representation 493 header fields beyond those required above, because the client is 494 understood to already have a prior response containing those header 495 fields. Otherwise, the sender MUST generate all of the 496 representation header fields that would have been sent in a 200 (OK) 497 response to the same request. 499 A 206 response is cacheable unless otherwise indicated by explicit 500 cache controls (see Section 4.1.2 of [Part6]). 502 4.2. Content-Range 504 The "Content-Range" header field is sent in a single part 206 505 (Partial Content) response to indicate the partial range of the 506 selected representation enclosed as the message payload, sent in each 507 part of a multipart 206 response to indicate the range enclosed 508 within each body part, and sent in 416 (Range Not Satisfiable) 509 responses to provide information about the selected representation. 511 Content-Range = byte-content-range 512 / other-content-range 514 byte-content-range = bytes-unit SP 515 ( byte-range-resp / unsatisfied-range ) 517 byte-range-resp = byte-range "/" ( complete-length / "*" ) 518 byte-range = first-byte-pos "-" last-byte-pos 519 unsatisfied-range = "*/" complete-length 521 complete-length = 1*DIGIT 523 other-content-range = other-range-unit SP other-range-resp 524 other-range-resp = *CHAR 526 If a 206 (Partial Content) response contains a Content-Range header 527 field with a range unit (Section 2) that the recipient does not 528 understand, the recipient MUST NOT attempt to recombine it with a 529 stored representation. A proxy that receives such a message SHOULD 530 forward it downstream. 532 For byte ranges, a sender SHOULD indicate the complete length of the 533 representation from which the range has been extracted, unless the 534 complete length is unknown or difficult to determine. An asterisk 535 character ("*") in place of the complete-length indicates that the 536 representation length was unknown when the header field was 537 generated. 539 The following example illustrates when the complete length of the 540 selected representation is known by the sender to be 1234 bytes: 542 Content-Range: bytes 42-1233/1234 544 and this second example illustrates when the complete length is 545 unknown: 547 Content-Range: bytes 42-1233/* 549 A Content-Range field value is invalid if it contains a byte-range- 550 resp that has a last-byte-pos value less than its first-byte-pos 551 value, or a complete-length value less than or equal to its last- 552 byte-pos value. The recipient of an invalid Content-Range MUST NOT 553 attempt to recombine the received content with a stored 554 representation. 556 A server generating a 416 (Range Not Satisfiable) response to a byte 557 range request SHOULD send a Content-Range header field with an 558 unsatisfied-range value, as in the following example: 560 Content-Range: bytes */1234 562 The complete-length in a 416 response indicates the current length of 563 the selected representation. 565 The "Content-Range" header field has no meaning for status codes that 566 do not explicitly describe its semantic. For this specification, 567 only the 206 (Partial Content) and 416 (Range Not Satisfiable) status 568 codes describe a meaning for Content-Range. 570 The following are examples of Content-Range values in which the 571 selected representation contains a total of 1234 bytes: 573 o The first 500 bytes: 575 Content-Range: bytes 0-499/1234 577 o The second 500 bytes: 579 Content-Range: bytes 500-999/1234 581 o All except for the first 500 bytes: 583 Content-Range: bytes 500-1233/1234 585 o The last 500 bytes: 587 Content-Range: bytes 734-1233/1234 589 4.3. Combining Ranges 591 A response might transfer only a subrange of a representation if the 592 connection closed prematurely or if the request used one or more 593 Range specifications. After several such transfers, a client might 594 have received several ranges of the same representation. These 595 ranges can only be safely combined if they all have in common the 596 same strong validator, where "strong validator" is defined to be 597 either an entity-tag that is not marked as weak (Section 2.3 of 598 [Part4]) or, if no entity-tag is provided, a Last-Modified value that 599 is strong in the sense defined by Section 2.2.2 of [Part4]. 601 A client that has received multiple partial responses to GET requests 602 on a target resource MAY combine those responses into a larger 603 continuous range if they share the same strong validator. 605 If the most recent response is an incomplete 200 (OK) response, then 606 the header fields of that response are used for any combined response 607 and replace those of the matching stored responses. 609 If the most recent response is a 206 (Partial Content) response and 610 at least one of the matching stored responses is a 200 (OK), then the 611 combined response header fields consist of the most recent 200 612 response's header fields. If all of the matching stored responses 613 are 206 responses, then the stored response with the most recent 614 header fields is used as the source of header fields for the combined 615 response, except that the client MUST use other header fields 616 provided in the new response, aside from Content-Range, to replace 617 all instances of the corresponding header fields in the stored 618 response. 620 The combined response message body consists of the union of partial 621 content ranges in the new response and each of the selected 622 responses. If the union consists of the entire range of the 623 representation, then the client MUST process the combined response as 624 if it were a complete 200 (OK) response, including a Content-Length 625 header field that reflects the complete length. Otherwise, the 626 client MUST process the set of continuous ranges as one of the 627 following: an incomplete 200 (OK) response if the combined response 628 is a prefix of the representation, a single 206 (Partial Content) 629 response containing a multipart/byteranges body, or multiple 206 630 (Partial Content) responses, each with one continuous range that is 631 indicated by a Content-Range header field. 633 4.4. 416 Range Not Satisfiable 635 The 416 (Range Not Satisfiable) status code indicates that none of 636 the ranges in the request's Range header field (Section 3.1) overlap 637 the current extent of the selected resource or that the set of ranges 638 requested has been rejected due to invalid ranges or an excessive 639 request of small or overlapping ranges. 641 For byte ranges, failing to overlap the current extent means that the 642 first-byte-pos of all of the byte-range-spec values were greater than 643 the current length of the selected representation. When this status 644 code is generated in response to a byte range request, the sender 645 SHOULD generate a Content-Range header field specifying the current 646 length of the selected representation (Section 4.2). 648 For example: 650 HTTP/1.1 416 Range Not Satisfiable 651 Date: Fri, 20 Jan 2012 15:41:54 GMT 652 Content-Range: bytes */47022 654 Note: Because servers are free to ignore Range, many 655 implementations will simply respond with the entire selected 656 representation in a 200 (OK) response. That is partly because 657 most clients are prepared to receive a 200 (OK) to complete the 658 task (albeit less efficiently) and partly because clients might 659 not stop making an invalid partial request until they have 660 received a complete representation. Thus, clients cannot depend 661 on receiving a 416 (Range Not Satisfiable) response even when it 662 is most appropriate. 664 5. IANA Considerations 666 5.1. Range Unit Registry 668 The HTTP Range Unit Registry defines the name space for the range 669 unit names and refers to their corresponding specifications. The 670 registry will be created and maintained at 671 . 673 5.1.1. Procedure 675 Registration of an HTTP Range Unit MUST include the following fields: 677 o Name 679 o Description 681 o Pointer to specification text 683 Values to be added to this name space require IETF Review (see 684 [RFC5226], Section 4.1). 686 5.1.2. Registrations 688 The initial HTTP Range Unit Registry shall contain the registrations 689 below: 691 +-------------+---------------------------------------+-------------+ 692 | Range Unit | Description | Reference | 693 | Name | | | 694 +-------------+---------------------------------------+-------------+ 695 | bytes | a range of octets | Section 2.1 | 696 | none | reserved as keyword, indicating no | Section 2.3 | 697 | | ranges are supported | | 698 +-------------+---------------------------------------+-------------+ 700 The change controller is: "IETF (iesg@ietf.org) - Internet 701 Engineering Task Force". 703 5.2. Status Code Registration 705 The HTTP Status Code Registry located at 706 shall be updated 707 with the registrations below: 709 +-------+-----------------------+-------------+ 710 | Value | Description | Reference | 711 +-------+-----------------------+-------------+ 712 | 206 | Partial Content | Section 4.1 | 713 | 416 | Range Not Satisfiable | Section 4.4 | 714 +-------+-----------------------+-------------+ 716 5.3. Header Field Registration 718 HTTP header fields are registered within the Message Header Field 719 Registry maintained at . 722 This document defines the following HTTP header fields, so their 723 associated registry entries shall be updated according to the 724 permanent registrations below (see [BCP90]): 726 +-------------------+----------+----------+-------------+ 727 | Header Field Name | Protocol | Status | Reference | 728 +-------------------+----------+----------+-------------+ 729 | Accept-Ranges | http | standard | Section 2.3 | 730 | Content-Range | http | standard | Section 4.2 | 731 | If-Range | http | standard | Section 3.2 | 732 | Range | http | standard | Section 3.1 | 733 +-------------------+----------+----------+-------------+ 735 The change controller is: "IETF (iesg@ietf.org) - Internet 736 Engineering Task Force". 738 6. Security Considerations 740 This section is meant to inform developers, information providers, 741 and users of known security concerns specific to the HTTP/1.1 range 742 request mechanisms. More general security considerations are 743 addressed in HTTP messaging [Part1] and semantics [Part2]. 745 6.1. Denial of Service Attacks using Range 747 Unconstrained multiple range requests are susceptible to denial of 748 service attacks because the effort required to request many 749 overlapping ranges of the same data is tiny compared to the time, 750 memory, and bandwidth consumed by attempting to serve the requested 751 data in many parts. Servers ought to ignore, coalesce, or reject 752 egregious range requests, such as requests for more than two 753 overlapping ranges or for many small ranges in a single set, 754 particularly when the ranges are requested out of order for no 755 apparent reason. Multipart range requests are not designed to 756 support random access. 758 7. Acknowledgments 760 See Section 9 of [Part1]. 762 8. References 764 8.1. Normative References 766 [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 767 Protocol (HTTP/1.1): Message Syntax and Routing", 768 draft-ietf-httpbis-p1-messaging-23 (work in progress), 769 July 2013. 771 [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 772 Protocol (HTTP/1.1): Semantics and Content", 773 draft-ietf-httpbis-p2-semantics-23 (work in progress), 774 July 2013. 776 [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 777 Protocol (HTTP/1.1): Conditional Requests", 778 draft-ietf-httpbis-p4-conditional-23 (work in progress), 779 July 2013. 781 [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 782 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 783 draft-ietf-httpbis-p6-cache-23 (work in progress), 784 July 2013. 786 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 787 Extensions (MIME) Part Two: Media Types", RFC 2046, 788 November 1996. 790 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 791 Requirement Levels", BCP 14, RFC 2119, March 1997. 793 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 794 Specifications: ABNF", STD 68, RFC 5234, January 2008. 796 8.2. Informative References 798 [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type 799 Specifications and Registration Procedures", BCP 13, 800 RFC 6838, January 2013. 802 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration 803 Procedures for Message Header Fields", BCP 90, RFC 3864, 804 September 2004. 806 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 807 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 808 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 810 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 811 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 812 May 2008. 814 Appendix A. Internet Media Type multipart/byteranges 816 When a 206 (Partial Content) response message includes the content of 817 multiple ranges, they are transmitted as body parts in a multipart 818 message body ([RFC2046], Section 5.1) with the media type of 819 "multipart/byteranges". The following definition is to be registered 820 with IANA [BCP13]. 822 The multipart/byteranges media type includes one or more body parts, 823 each with its own Content-Type and Content-Range fields. The 824 required boundary parameter specifies the boundary string used to 825 separate each body part. 827 Type name: multipart 829 Subtype name: byteranges 831 Required parameters: boundary 833 Optional parameters: none 835 Encoding considerations: only "7bit", "8bit", or "binary" are 836 permitted 838 Security considerations: none 840 Interoperability considerations: none 842 Published specification: This specification (see Appendix A). 844 Applications that use this media type: HTTP components supporting 845 multiple ranges in a single request. 847 Additional information: 849 Magic number(s): none 851 File extension(s): none 853 Macintosh file type code(s): none 855 Person and email address to contact for further information: See 856 Authors Section. 858 Intended usage: COMMON 860 Restrictions on usage: none 862 Author: See Authors Section. 864 Change controller: IESG 866 Implementation Notes: 868 1. Additional CRLFs might precede the first boundary string in the 869 body. 871 2. Although [RFC2046] permits the boundary string to be quoted, some 872 existing implementations handle a quoted boundary string 873 incorrectly. 875 3. A number of clients and servers were coded to an early draft of 876 the byteranges specification that used a media type of multipart/ 877 x-byteranges, which is almost (but not quite) compatible with 878 this type. 880 Despite the name, the "multipart/byteranges" media type is not 881 limited to byte ranges. The following example uses an "exampleunit" 882 range unit: 884 HTTP/1.1 206 Partial Content 885 Date: Tue, 14 Nov 1995 06:25:24 GMT 886 Last-Modified: Tue, 14 July 04:58:08 GMT 887 Content-Length: 2331785 888 Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES 890 --THIS_STRING_SEPARATES 891 Content-Type: video/example 892 Content-Range: exampleunit 1.2-4.3/25 894 ...the first range... 895 --THIS_STRING_SEPARATES 896 Content-Type: video/example 897 Content-Range: exampleunit 11.2-14.3/25 899 ...the second range 900 --THIS_STRING_SEPARATES-- 902 Appendix B. Changes from RFC 2616 904 A weak validator cannot be used in a 206 response. (Section 4.1) 906 The Content-Range header field only has meaning when the status code 907 explicitly defines its use. (Section 4.2) 909 Servers are given more leeway in how they respond to a range request, 910 in order to mitigate abuse by malicious (or just greedy) clients. 912 multipart/byteranges can consist of a single part. (Appendix A) 914 This specification introduces a Range Unit Registry. (Section 5.1) 916 Appendix C. Imported ABNF 918 The following core rules are included by reference, as defined in 919 Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), 920 CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double 921 quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 922 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII 923 character). 925 Note that all rules derived from token are to be compared case- 926 insensitively, like range-unit and acceptable-ranges. 928 The rules below are defined in [Part1]: 930 OWS = 931 token = 933 The rules below are defined in other parts: 935 HTTP-date = 936 entity-tag = 938 Appendix D. Collected ABNF 940 In the collected ABNF below, list rules are expanded as per Section 941 1.2 of [Part1]. 943 Accept-Ranges = acceptable-ranges 945 Content-Range = byte-content-range / other-content-range 947 HTTP-date = 949 If-Range = entity-tag / HTTP-date 951 OWS = 953 Range = byte-ranges-specifier / other-ranges-specifier 955 acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS 956 range-unit ] ) ) / "none" 958 byte-content-range = bytes-unit SP ( byte-range-resp / 959 unsatisfied-range ) 960 byte-range = first-byte-pos "-" last-byte-pos 961 byte-range-resp = byte-range "/" ( complete-length / "*" ) 962 byte-range-set = *( "," OWS ) ( byte-range-spec / 963 suffix-byte-range-spec ) *( OWS "," [ OWS ( byte-range-spec / 964 suffix-byte-range-spec ) ] ) 965 byte-range-spec = first-byte-pos "-" [ last-byte-pos ] 966 byte-ranges-specifier = bytes-unit "=" byte-range-set 967 bytes-unit = "bytes" 969 complete-length = 1*DIGIT 971 entity-tag = 973 first-byte-pos = 1*DIGIT 975 last-byte-pos = 1*DIGIT 977 other-content-range = other-range-unit SP other-range-resp 978 other-range-resp = *CHAR 979 other-range-set = 1*CHAR 980 other-range-unit = token 981 other-ranges-specifier = other-range-unit "=" other-range-set 983 range-unit = bytes-unit / other-range-unit 985 suffix-byte-range-spec = "-" suffix-length 986 suffix-length = 1*DIGIT 988 token = 990 unsatisfied-range = "*/" complete-length 992 Appendix E. Change Log (to be removed by RFC Editor before publication) 994 Changes up to the first Working Group Last Call draft are summarized 995 in . 998 E.1. Since draft-ietf-httpbis-p5-range-19 1000 Closed issues: 1002 o : "ABNF list 1003 expansion code problem" 1005 o : "ABNF 1006 requirements for recipients" 1008 o : "reserve 1009 'none' as byte range unit" 1011 o : "note 1012 introduction of new IANA registries as normative changes" 1014 o : "range units 1015 vs leading zeroes vs size" 1017 E.2. Since draft-ietf-httpbis-p5-range-20 1019 o Conformance criteria and considerations regarding error handling 1020 are now defined in Part 1. 1022 E.3. Since draft-ietf-httpbis-p5-range-21 1024 Closed issues: 1026 o : "Security 1027 consideration: range flooding" 1029 o : "Allowing 1030 heuristic caching for new status codes" 1032 o : "Add 1033 limitations to Range to reduce its use as a denial-of-service 1034 tool" 1036 o : "416 and 1037 multipart/byteranges" 1039 E.4. Since draft-ietf-httpbis-p5-range-22 1041 Closed issues: 1043 o : "explain list 1044 expansion in ABNF appendices" 1046 o : "incorrect 1047 example dates" 1049 o : "media type 1050 registration template issues" 1052 o : "Editorial 1053 suggestions" 1055 o : "MUSTs and 1056 other feedback" 1058 Index 1060 2 1061 206 Partial Content (status code) 10 1063 4 1064 416 Range Not Satisfiable (status code) 15 1066 A 1067 Accept-Ranges header field 7 1069 C 1070 Content-Range header field 12 1072 G 1073 Grammar 1074 Accept-Ranges 7 1075 acceptable-ranges 7 1076 byte-content-range 12 1077 byte-range 12 1078 byte-range-resp 12 1079 byte-range-set 5 1080 byte-range-spec 5 1081 byte-ranges-specifier 5 1082 bytes-unit 5 1083 complete-length 12 1084 Content-Range 12 1085 first-byte-pos 5 1086 If-Range 9 1087 last-byte-pos 5 1088 other-content-range 12 1089 other-range-resp 12 1090 other-range-unit 5, 7 1091 Range 7 1092 range-unit 5 1093 ranges-specifier 5 1094 suffix-byte-range-spec 6 1095 suffix-length 6 1096 unsatisfied-range 12 1098 I 1099 If-Range header field 9 1101 M 1102 Media Type 1103 multipart/byteranges 18 1104 multipart/x-byteranges 20 1105 multipart/byteranges Media Type 18 1106 multipart/x-byteranges Media Type 20 1108 R 1109 Range header field 7 1111 Authors' Addresses 1113 Roy T. Fielding (editor) 1114 Adobe Systems Incorporated 1115 345 Park Ave 1116 San Jose, CA 95110 1117 USA 1119 EMail: fielding@gbiv.com 1120 URI: http://roy.gbiv.com/ 1122 Yves Lafon (editor) 1123 World Wide Web Consortium 1124 W3C / ERCIM 1125 2004, rte des Lucioles 1126 Sophia-Antipolis, AM 06902 1127 France 1129 EMail: ylafon@w3.org 1130 URI: http://www.raubacapeu.net/people/yves/ 1131 Julian F. Reschke (editor) 1132 greenbytes GmbH 1133 Hafenweg 16 1134 Muenster, NW 48155 1135 Germany 1137 EMail: julian.reschke@greenbytes.de 1138 URI: http://greenbytes.de/tech/webdav/