idnits 2.17.1 draft-ietf-httpbis-p5-range-21.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 (October 4, 2012) is 4219 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: 'Part2' is defined on line 708, but no explicit reference was found in the text == Unused Reference: 'RFC2616' is defined on line 735, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-21 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-21 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-21 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-21 -- 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 4288 (Obsoleted by RFC 6838) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 7 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: April 7, 2013 J. Reschke, Ed. 7 greenbytes 8 October 4, 2012 10 Hypertext Transfer Protocol (HTTP/1.1): Range Requests 11 draft-ietf-httpbis-p5-range-21 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.2. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 7, 2013. 50 Copyright Notice 52 Copyright (c) 2012 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. Range Specifier Registry . . . . . . . . . . . . . . . . . 5 84 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5 85 3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 5 86 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 6 87 4. Responses to a Range Request . . . . . . . . . . . . . . . . . 7 88 4.1. Response to a Single and Multiple Ranges Request . . . . . 7 89 4.2. Combining Ranges . . . . . . . . . . . . . . . . . . . . . 7 90 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 8 91 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 8 92 5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 9 93 5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 10 94 5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 11 95 5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 11 96 5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 13 97 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 98 6.1. Status Code Registration . . . . . . . . . . . . . . . . . 14 99 6.2. Header Field Registration . . . . . . . . . . . . . . . . 15 100 6.3. Range Specifier Registration . . . . . . . . . . . . . . . 15 101 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 102 7.1. Overlapping Ranges . . . . . . . . . . . . . . . . . . . . 16 103 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 104 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 105 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 106 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 107 Appendix A. Internet Media Type multipart/byteranges . . . . . . 17 108 Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 19 109 Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 19 110 Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 21 111 Appendix E. Change Log (to be removed by RFC Editor before 112 publication) . . . . . . . . . . . . . . . . . . . . 22 113 E.1. Since draft-ietf-httpbis-p5-range-19 . . . . . . . . . . . 22 114 E.2. Since draft-ietf-httpbis-p5-range-20 . . . . . . . . . . . 22 115 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 117 1. Introduction 119 HTTP clients often encounter interrupted data transfers as a result 120 of canceled requests or dropped connections. When a client has 121 stored a partial representation, it is desirable to request the 122 remainder of that representation in a subsequent request rather than 123 transfer the entire representation. There are also a number of Web 124 applications that benefit from being able to request only a subset of 125 a larger representation, such as a single page of a very large 126 document or only part of an image to be rendered by a device with 127 limited local storage. 129 This document defines HTTP/1.1 range requests, partial responses, and 130 the multipart/byteranges media type. The protocol for range requests 131 is an OPTIONAL feature of HTTP, designed so resources or recipients 132 that do not implement this feature can respond as if it is a normal 133 GET request without impacting interoperability. Partial responses 134 are indicated by a distinct status code to not be mistaken for full 135 responses by intermediate caches that might not implement the 136 feature. 138 Although the HTTP range request mechanism is designed to allow for 139 extensible range types, this specification only defines requests for 140 byte ranges. 142 1.1. Conformance and Error Handling 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 Conformance criteria and considerations regarding error handling are 149 defined in Section 2.5 of [Part1]. 151 1.2. Syntax Notation 153 This specification uses the Augmented Backus-Naur Form (ABNF) 154 notation of [RFC5234] with the list rule extension defined in Section 155 1.2 of [Part1]. Appendix C describes rules imported from other 156 documents. Appendix D shows the collected ABNF with the list rule 157 expanded. 159 2. Range Units 161 HTTP/1.1 allows a client to request that only part (a range) of the 162 representation be included within the response. HTTP/1.1 uses range 163 units in the Range (Section 5.4) and Content-Range (Section 5.2) 164 header fields. A representation can be broken down into subranges 165 according to various structural units. 167 range-unit = bytes-unit / other-range-unit 168 bytes-unit = "bytes" 169 other-range-unit = token 171 HTTP/1.1 has been designed to allow implementations of applications 172 that do not depend on knowledge of ranges. The only range unit 173 defined by HTTP/1.1 is "bytes". Additional specifiers can be defined 174 as described in Section 2.1. 176 If a range unit is not understood in a request, a server MUST ignore 177 the whole Range header field (Section 5.4). If a range unit is not 178 understood in a response, an intermediary SHOULD pass the response to 179 the client; a client MUST fail. 181 2.1. Range Specifier Registry 183 The HTTP Range Specifier Registry defines the name space for the 184 range specifier names. 186 Registrations MUST include the following fields: 188 o Name 190 o Description 192 o Pointer to specification text 194 Values to be added to this name space require IETF Review (see 195 [RFC5226], Section 4.1). 197 The registry itself is maintained at 198 . 200 3. Status Code Definitions 202 3.1. 206 Partial Content 204 The server has fulfilled the partial GET request for the resource. 205 The request MUST have included a Range header field (Section 5.4) 206 indicating the desired range, and MAY have included an If-Range 207 header field (Section 5.3) to make the request conditional. 209 The response MUST include the following header fields: 211 o Either a Content-Range header field (Section 5.2) indicating the 212 range included with this response, or a multipart/byteranges 213 Content-Type including Content-Range fields for each part. If a 214 Content-Length header field is present in the response, its value 215 MUST match the actual number of octets transmitted in the message 216 body. 218 o Date 220 o Cache-Control, ETag, Expires, Content-Location and/or Vary, if the 221 header field would have been sent in a 200 (OK) response to the 222 same request 224 If a 206 is sent in response to a request with an If-Range header 225 field, it SHOULD NOT include other representation header fields. 226 Otherwise, the response MUST include all of the representation header 227 fields that would have been returned with a 200 (OK) response to the 228 same request. 230 Caches MAY use a heuristic (see Section 4.1.2 of [Part6]) to 231 determine freshness for 206 responses. 233 3.2. 416 Requested Range Not Satisfiable 235 A server SHOULD return a response with this status code if a request 236 included a Range header field (Section 5.4), and none of the ranges- 237 specifier values in this field overlap the current extent of the 238 selected resource, and the request did not include an If-Range header 239 field (Section 5.3). (For byte-ranges, this means that the first- 240 byte-pos of all of the byte-range-spec values were greater than the 241 current length of the selected resource.) 243 When this status code is returned for a byte-range request, the 244 response SHOULD include a Content-Range header field specifying the 245 current length of the representation (see Section 5.2). This 246 response MUST NOT use the multipart/byteranges content-type. For 247 example, 249 HTTP/1.1 416 Requested Range Not Satisfiable 250 Date: Mon, 20 Jan 2012 15:41:54 GMT 251 Content-Range: bytes */47022 252 Content-Type: image/gif 254 Note: Clients cannot depend on servers to send a 416 (Requested 255 Range Not Satisfiable) response instead of a 200 (OK) response for 256 an unsatisfiable Range header field, since not all servers 257 implement this header field. 259 4. Responses to a Range Request 261 4.1. Response to a Single and Multiple Ranges Request 263 When an HTTP message includes the content of a single range (for 264 example, a response to a request for a single range, or to a request 265 for a set of ranges that overlap without any holes), this content is 266 transmitted with a Content-Range header field, and a Content-Length 267 header field showing the number of bytes actually transferred. For 268 example, 270 HTTP/1.1 206 Partial Content 271 Date: Wed, 15 Nov 1995 06:25:24 GMT 272 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 273 Content-Range: bytes 21010-47021/47022 274 Content-Length: 26012 275 Content-Type: image/gif 277 When an HTTP message includes the content of multiple ranges (for 278 example, a response to a request for multiple non-overlapping 279 ranges), these are transmitted as a multipart message. The multipart 280 media type used for this purpose is "multipart/byteranges" as defined 281 in Appendix A. 283 A server MAY combine requested ranges when those ranges are 284 overlapping (see Section 7.1). 286 A response to a request for a single range MUST NOT be sent using the 287 multipart/byteranges media type. A response to a request for 288 multiple ranges, whose result is a single range, MAY be sent as a 289 multipart/byteranges media type with one part. A client that cannot 290 decode a multipart/byteranges message MUST NOT ask for multiple 291 ranges in a single request. 293 When a client asks for multiple ranges in one request, the server 294 SHOULD return them in the order that they appeared in the request. 296 4.2. Combining Ranges 298 A response might transfer only a subrange of a representation if the 299 connection closed prematurely or if the request used one or more 300 Range specifications. After several such transfers, a client might 301 have received several ranges of the same representation. These 302 ranges can only be safely combined if they all have in common the 303 same strong validator, where "strong validator" is defined to be 304 either an entity-tag that is not marked as weak (Section 2.3 of 305 [Part4]) or, if no entity-tag is provided, a Last-Modified value that 306 is strong in the sense defined by Section 2.2.2 of [Part4]. 308 When a client receives an incomplete 200 (OK) or 206 (Partial 309 Content) response and already has one or more stored responses for 310 the same method and effective request URI, all of the stored 311 responses with the same strong validator MAY be combined with the 312 partial content in this new response. If none of the stored 313 responses contain the same strong validator, then this new response 314 corresponds to a new representation and MUST NOT be combined with the 315 existing stored responses. 317 If the new response is an incomplete 200 (OK) response, then the 318 header fields of that new response are used for any combined response 319 and replace those of the matching stored responses. 321 If the new response is a 206 (Partial Content) response and at least 322 one of the matching stored responses is a 200 (OK), then the combined 323 response header fields consist of the most recent 200 response's 324 header fields. If all of the matching stored responses are 206 325 responses, then the stored response with the most header fields is 326 used as the source of header fields for the combined response, except 327 that the client MUST use other header fields provided in the new 328 response, aside from Content-Range, to replace all instances of the 329 corresponding header fields in the stored response. 331 The combined response message body consists of the union of partial 332 content ranges in the new response and each of the selected 333 responses. If the union consists of the entire range of the 334 representation, then the combined response MUST be recorded as a 335 complete 200 (OK) response with a Content-Length header field that 336 reflects the complete length. Otherwise, the combined response(s) 337 MUST include a Content-Range header field describing the included 338 range(s) and be recorded as incomplete. If the union consists of a 339 discontinuous range of the representation, then the client MAY store 340 it as either a multipart range response or as multiple 206 responses 341 with one continuous range each. 343 5. Header Field Definitions 345 This section defines the syntax and semantics of HTTP/1.1 header 346 fields related to range requests and partial responses. 348 5.1. Accept-Ranges 350 The "Accept-Ranges" header field allows a resource to indicate its 351 acceptance of range requests. 353 Accept-Ranges = acceptable-ranges 354 acceptable-ranges = 1#range-unit / "none" 356 Origin servers that accept byte-range requests MAY send 358 Accept-Ranges: bytes 360 but are not required to do so. Clients MAY generate range requests 361 without having received this header field for the resource involved. 362 Range units are defined in Section 2. 364 Servers that do not accept any kind of range request for a resource 365 MAY send 367 Accept-Ranges: none 369 to advise the client not to attempt a range request. 371 5.2. Content-Range 373 The "Content-Range" header field is sent with a partial 374 representation to specify where in the full representation the 375 payload body is intended to be applied. 377 Range units are defined in Section 2. 379 Content-Range = byte-content-range-spec 380 / other-content-range-spec 382 byte-content-range-spec = bytes-unit SP 383 byte-range-resp-spec "/" 384 ( instance-length / "*" ) 386 byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) 387 / "*" 389 instance-length = 1*DIGIT 391 other-content-range-spec = other-range-unit SP 392 other-range-resp-spec 393 other-range-resp-spec = *CHAR 395 The header field SHOULD indicate the total length of the full 396 representation, unless this length is unknown or difficult to 397 determine. The asterisk "*" character means that the instance-length 398 is unknown at the time when the response was generated. 400 Unlike byte-ranges-specifier values (see Section 5.4.1), a byte- 401 range-resp-spec MUST only specify one range, and MUST contain 402 absolute byte positions for both the first and last byte of the 403 range. 405 A byte-content-range-spec with a byte-range-resp-spec whose last- 406 byte-pos value is less than its first-byte-pos value, or whose 407 instance-length value is less than or equal to its last-byte-pos 408 value, is invalid. The recipient of an invalid byte-content-range- 409 spec MUST ignore it and any content transferred along with it. 411 In the case of a byte range request: A server sending a response with 412 status code 416 (Requested Range Not Satisfiable) SHOULD include a 413 Content-Range field with a byte-range-resp-spec of "*". The 414 instance-length specifies the current length of the selected 415 resource. A response with status code 206 (Partial Content) MUST NOT 416 include a Content-Range field with a byte-range-resp-spec of "*". 418 The "Content-Range" header field has no meaning for status codes that 419 do not explicitly describe its semantic. Currently, only status 420 codes 206 (Partial Content) and 416 (Requested Range Not Satisfiable) 421 describe the meaning of this header field. 423 Examples of byte-content-range-spec values, assuming that the 424 representation contains a total of 1234 bytes: 426 o The first 500 bytes: 428 bytes 0-499/1234 430 o The second 500 bytes: 432 bytes 500-999/1234 434 o All except for the first 500 bytes: 436 bytes 500-1233/1234 438 o The last 500 bytes: 440 bytes 734-1233/1234 442 If the server ignores a byte-range-spec (for example if it is 443 syntactically invalid, or if it might be seen as a denial-of-service 444 attack), the server SHOULD treat the request as if the invalid Range 445 header field did not exist. (Normally, this means return a 200 (OK) 446 response containing the full representation). 448 5.3. If-Range 450 If a client has a partial copy of a representation and wishes to have 451 an up-to-date copy of the entire representation, it could use the 452 Range header field with a conditional GET (using either or both of 453 If-Unmodified-Since and If-Match.) However, if the condition fails 454 because the representation has been modified, the client would then 455 have to make a second request to obtain the entire current 456 representation. 458 The "If-Range" header field allows a client to "short-circuit" the 459 second request. Informally, its meaning is "if the representation is 460 unchanged, send me the part(s) that I am missing; otherwise, send me 461 the entire new representation". 463 If-Range = entity-tag / HTTP-date 465 Clients MUST NOT use an entity-tag marked as weak in an If-Range 466 field value and MUST NOT use a Last-Modified date in an If-Range 467 field value unless it has no entity-tag for the representation and 468 the Last-Modified date it does have for the representation is strong 469 in the sense defined by Section 2.2.2 of [Part4]. 471 A server that evaluates a conditional range request that is 472 applicable to one of its representations MUST evaluate the condition 473 as false if the entity-tag used as a validator is marked as weak or, 474 when an HTTP-date is used as the validator, if the date value is not 475 strong in the sense defined by Section 2.2.2 of [Part4]. (A server 476 can distinguish between a valid HTTP-date and any form of entity-tag 477 by examining the first two characters.) 479 The If-Range header field SHOULD only be sent by clients together 480 with a Range header field. The If-Range header field MUST be ignored 481 if it is received in a request that does not include a Range header 482 field. The If-Range header field MUST be ignored by a server that 483 does not support the sub-range operation. 485 If the validator given in the If-Range header field matches the 486 current validator for the selected representation of the target 487 resource, then the server SHOULD send the specified sub-range of the 488 representation using a 206 (Partial Content) response. If the 489 validator does not match, then the server SHOULD send the entire 490 representation using a 200 (OK) response. 492 5.4. Range 494 5.4.1. Byte Ranges 496 Since all HTTP representations are transferred as sequences of bytes, 497 the concept of a byte range is meaningful for any HTTP 498 representation. (However, not all clients and servers need to 499 support byte-range operations.) 500 Byte range specifications in HTTP apply to the sequence of bytes in 501 the representation data (not necessarily the same as the message 502 body). 504 A byte range operation MAY specify a single range of bytes, or a set 505 of ranges within a single representation. 507 byte-ranges-specifier = bytes-unit "=" byte-range-set 508 byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec ) 509 byte-range-spec = first-byte-pos "-" [ last-byte-pos ] 510 first-byte-pos = 1*DIGIT 511 last-byte-pos = 1*DIGIT 513 The first-byte-pos value in a byte-range-spec gives the byte-offset 514 of the first byte in a range. The last-byte-pos value gives the 515 byte-offset of the last byte in the range; that is, the byte 516 positions specified are inclusive. Byte offsets start at zero. 518 If the last-byte-pos value is present, it MUST be greater than or 519 equal to the first-byte-pos in that byte-range-spec, or the byte- 520 range-spec is syntactically invalid. The recipient of a byte-range- 521 set that includes one or more syntactically invalid byte-range-spec 522 values MUST ignore the header field that includes that byte-range- 523 set. 525 If the last-byte-pos value is absent, or if the value is greater than 526 or equal to the current length of the representation data, last-byte- 527 pos is taken to be equal to one less than the current length of the 528 representation in bytes. 530 By its choice of last-byte-pos, a client can limit the number of 531 bytes retrieved without knowing the size of the representation. 533 suffix-byte-range-spec = "-" suffix-length 534 suffix-length = 1*DIGIT 536 A suffix-byte-range-spec is used to specify the suffix of the 537 representation data, of a length given by the suffix-length value. 538 (That is, this form specifies the last N bytes of a representation.) 539 If the representation is shorter than the specified suffix-length, 540 the entire representation is used. 542 If a syntactically valid byte-range-set includes at least one byte- 543 range-spec whose first-byte-pos is less than the current length of 544 the representation, or at least one suffix-byte-range-spec with a 545 non-zero suffix-length, then the byte-range-set is satisfiable. 546 Otherwise, the byte-range-set is unsatisfiable. If the byte-range- 547 set is unsatisfiable, the server SHOULD return a response with a 416 548 (Requested Range Not Satisfiable) status code. Otherwise, the server 549 SHOULD return a response with a 206 (Partial Content) status code 550 containing the satisfiable ranges of the representation. 552 In the byte range syntax, first-byte-pos, last-byte-pos, and suffix- 553 length are expressed as decimal number of octets. Since there is no 554 predefined limit to the length of an HTTP payload, recipients SHOULD 555 anticipate potentially large decimal numerals and prevent parsing 556 errors due to integer conversion overflows. 558 Examples of byte-ranges-specifier values (assuming a representation 559 of length 10000): 561 o The first 500 bytes (byte offsets 0-499, inclusive): 563 bytes=0-499 565 o The second 500 bytes (byte offsets 500-999, inclusive): 567 bytes=500-999 569 o The final 500 bytes (byte offsets 9500-9999, inclusive): 571 bytes=-500 573 Or: 575 bytes=9500- 577 o The first and last bytes only (bytes 0 and 9999): 579 bytes=0-0,-1 581 o Several legal but not canonical specifications of the second 500 582 bytes (byte offsets 500-999, inclusive): 584 bytes=500-600,601-999 585 bytes=500-700,601-999 587 5.4.2. Range Retrieval Requests 589 The "Range" header field defines the GET method (conditional or not) 590 to request one or more sub-ranges of the response representation 591 data, instead of the entire representation data. 593 Range = byte-ranges-specifier / other-ranges-specifier 594 other-ranges-specifier = other-range-unit "=" other-range-set 595 other-range-set = 1*CHAR 597 A server MAY ignore the Range header field. However, origin servers 598 and intermediate caches ought to support byte ranges when possible, 599 since Range supports efficient recovery from partially failed 600 transfers, and supports efficient partial retrieval of large 601 representations. 603 If the server supports the Range header field and the specified range 604 or ranges are appropriate for the representation: 606 o The presence of a Range header field in an unconditional GET 607 modifies what is returned if the GET is otherwise successful. In 608 other words, the response carries a status code of 206 (Partial 609 Content) instead of 200 (OK). 611 o The presence of a Range header field in a conditional GET (a 612 request using one or both of If-Modified-Since and If-None-Match, 613 or one or both of If-Unmodified-Since and If-Match) modifies what 614 is returned if the GET is otherwise successful and the condition 615 is true. It does not affect the 304 (Not Modified) response 616 returned if the conditional is false. 618 In some cases, it might be more appropriate to use the If-Range 619 header field (see Section 5.3) in addition to the Range header field. 621 If a proxy that supports ranges receives a Range request, forwards 622 the request to an inbound server, and receives an entire 623 representation in reply, it MAY only return the requested range to 624 its client. 626 6. IANA Considerations 628 6.1. Status Code Registration 630 The HTTP Status Code Registry located at 631 shall be updated 632 with the registrations below: 634 +-------+---------------------------------+-------------+ 635 | Value | Description | Reference | 636 +-------+---------------------------------+-------------+ 637 | 206 | Partial Content | Section 3.1 | 638 | 416 | Requested Range Not Satisfiable | Section 3.2 | 639 +-------+---------------------------------+-------------+ 641 6.2. Header Field Registration 643 The Message Header Field Registry located at shall be 645 updated with the permanent registrations below (see [RFC3864]): 647 +-------------------+----------+----------+-------------+ 648 | Header Field Name | Protocol | Status | Reference | 649 +-------------------+----------+----------+-------------+ 650 | Accept-Ranges | http | standard | Section 5.1 | 651 | Content-Range | http | standard | Section 5.2 | 652 | If-Range | http | standard | Section 5.3 | 653 | Range | http | standard | Section 5.4 | 654 +-------------------+----------+----------+-------------+ 656 The change controller is: "IETF (iesg@ietf.org) - Internet 657 Engineering Task Force". 659 6.3. Range Specifier Registration 661 The registration procedure for HTTP Range Specifiers is defined by 662 Section 2.1 of this document. 664 The HTTP Range Specifier Registry shall be created at 665 and be 666 populated with the registrations below: 668 +---------------+-------------------------------------+-------------+ 669 | Range | Description | Reference | 670 | Specifier | | | 671 | Name | | | 672 +---------------+-------------------------------------+-------------+ 673 | bytes | a range of octets | Section 2 | 674 | none | reserved as keyword, indicating no | Section 5.1 | 675 | | ranges are supported | | 676 +---------------+-------------------------------------+-------------+ 678 The change controller is: "IETF (iesg@ietf.org) - Internet 679 Engineering Task Force". 681 7. Security Considerations 683 This section is meant to inform application developers, information 684 providers, and users of the security limitations in HTTP/1.1 as 685 described by this document. The discussion does not include 686 definitive solutions to the problems revealed, though it does make 687 some suggestions for reducing security risks. 689 7.1. Overlapping Ranges 691 Range requests containing overlapping ranges can lead to the 692 situation where a server is sending far more data than the size of 693 the complete resource representation. 695 8. Acknowledgments 697 See Section 9 of [Part1]. 699 9. References 701 9.1. Normative References 703 [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 704 Protocol (HTTP/1.1): Message Syntax and Routing", 705 draft-ietf-httpbis-p1-messaging-21 (work in progress), 706 October 2012. 708 [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 709 Protocol (HTTP/1.1): Semantics and Content", 710 draft-ietf-httpbis-p2-semantics-21 (work in progress), 711 October 2012. 713 [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 714 Protocol (HTTP/1.1): Conditional Requests", 715 draft-ietf-httpbis-p4-conditional-21 (work in progress), 716 October 2012. 718 [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 719 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 720 draft-ietf-httpbis-p6-cache-21 (work in progress), 721 October 2012. 723 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 724 Extensions (MIME) Part Two: Media Types", RFC 2046, 725 November 1996. 727 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 728 Requirement Levels", BCP 14, RFC 2119, March 1997. 730 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 731 Specifications: ABNF", STD 68, RFC 5234, January 2008. 733 9.2. Informative References 735 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 736 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 737 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 739 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 740 Procedures for Message Header Fields", BCP 90, RFC 3864, 741 September 2004. 743 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 744 Registration Procedures", BCP 13, RFC 4288, December 2005. 746 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 747 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 748 May 2008. 750 Appendix A. Internet Media Type multipart/byteranges 752 When an HTTP 206 (Partial Content) response message includes the 753 content of multiple ranges (a response to a request for multiple non- 754 overlapping ranges), these are transmitted as a multipart message 755 body ([RFC2046], Section 5.1). The media type for this purpose is 756 called "multipart/byteranges". The following is to be registered 757 with IANA [RFC4288]. 759 The multipart/byteranges media type includes one or more parts, each 760 with its own Content-Type and Content-Range fields. The required 761 boundary parameter specifies the boundary string used to separate 762 each body-part. 764 Type name: multipart 766 Subtype name: byteranges 768 Required parameters: boundary 770 Optional parameters: none 772 Encoding considerations: only "7bit", "8bit", or "binary" are 773 permitted 775 Security considerations: none 777 Interoperability considerations: none 779 Published specification: This specification (see Appendix A). 781 Applications that use this media type: HTTP components supporting 782 multiple ranges in a single request. 784 Additional information: 786 Magic number(s): none 788 File extension(s): none 790 Macintosh file type code(s): none 792 Person and email address to contact for further information: See 793 Authors Section. 795 Intended usage: COMMON 797 Restrictions on usage: none 799 Author/Change controller: IESG 801 Note: Despite the name "multipart/byteranges" is not limited to 802 the byte ranges only. 804 For example: 806 HTTP/1.1 206 Partial Content 807 Date: Wed, 15 Nov 1995 06:25:24 GMT 808 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 809 Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES 811 --THIS_STRING_SEPARATES 812 Content-type: application/pdf 813 Content-range: bytes 500-999/8000 815 ...the first range... 816 --THIS_STRING_SEPARATES 817 Content-type: application/pdf 818 Content-range: bytes 7000-7999/8000 820 ...the second range 821 --THIS_STRING_SEPARATES-- 823 Another example, using the "exampleunit" range unit: 825 HTTP/1.1 206 Partial Content 826 Date: Tue, 14 Nov 1995 06:25:24 GMT 827 Last-Modified: Tue, 14 July 04:58:08 GMT 828 Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES 830 --THIS_STRING_SEPARATES 831 Content-type: video/example 832 Content-range: exampleunit 1.2-4.3/25 834 ...the first range... 835 --THIS_STRING_SEPARATES 836 Content-type: video/example 837 Content-range: exampleunit 11.2-14.3/25 839 ...the second range 840 --THIS_STRING_SEPARATES-- 842 Notes: 844 1. Additional CRLFs MAY precede the first boundary string in the 845 body. 847 2. Although [RFC2046] permits the boundary string to be quoted, some 848 existing implementations handle a quoted boundary string 849 incorrectly. 851 3. A number of clients and servers were coded to an early draft of 852 the byteranges specification to use a media type of multipart/ 853 x-byteranges, which is almost, but not quite compatible with the 854 version documented in HTTP/1.1. 856 Appendix B. Changes from RFC 2616 858 Introduce Range Specifier Registry. (Section 2.1) 860 Clarify that it is not ok to use a weak validator in a 206 response. 861 (Section 3.1) 863 Clarify that multipart/byteranges can consist of a single part. 864 (Appendix A) 866 Appendix C. Imported ABNF 868 The following core rules are included by reference, as defined in 869 Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), 870 CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double 871 quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 872 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII 873 character). 875 Note that all rules derived from token are to be compared case- 876 insensitively, like range-unit and acceptable-ranges. 878 The rules below are defined in [Part1]: 880 OWS = 881 token = 883 The rules below are defined in other parts: 885 HTTP-date = 886 entity-tag = 888 Appendix D. Collected ABNF 890 Accept-Ranges = acceptable-ranges 892 Content-Range = byte-content-range-spec / other-content-range-spec 894 HTTP-date = 896 If-Range = entity-tag / HTTP-date 898 OWS = 900 Range = byte-ranges-specifier / other-ranges-specifier 902 acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS 903 range-unit ] ) ) / "none" 905 byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" ( 906 instance-length / "*" ) 907 byte-range-resp-spec = ( first-byte-pos "-" last-byte-pos ) / "*" 908 byte-range-set = *( "," OWS ) ( byte-range-spec / 909 suffix-byte-range-spec ) *( OWS "," [ OWS ( byte-range-spec / 910 suffix-byte-range-spec ) ] ) 911 byte-range-spec = first-byte-pos "-" [ last-byte-pos ] 912 byte-ranges-specifier = bytes-unit "=" byte-range-set 913 bytes-unit = "bytes" 915 entity-tag = 917 first-byte-pos = 1*DIGIT 919 instance-length = 1*DIGIT 921 last-byte-pos = 1*DIGIT 923 other-content-range-spec = other-range-unit SP other-range-resp-spec 924 other-range-resp-spec = *CHAR 925 other-range-set = 1*CHAR 926 other-range-unit = token 927 other-ranges-specifier = other-range-unit "=" other-range-set 929 range-unit = bytes-unit / other-range-unit 931 suffix-byte-range-spec = "-" suffix-length 932 suffix-length = 1*DIGIT 934 token = 936 Appendix E. Change Log (to be removed by RFC Editor before publication) 938 Changes up to the first Working Group Last Call draft are summarized 939 in . 942 E.1. Since draft-ietf-httpbis-p5-range-19 944 Closed issues: 946 o : "ABNF list 947 expansion code problem" 949 o : "ABNF 950 requirements for recipients" 952 o : "reserve 953 'none' as byte range unit" 955 o : "note 956 introduction of new IANA registries as normative changes" 958 o : "range units 959 vs leading zeroes vs size" 961 E.2. Since draft-ietf-httpbis-p5-range-20 963 o Conformance criteria and considerations regarding error handling 964 are now defined in Part 1. 966 Index 968 2 969 206 Partial Content (status code) 5 971 4 972 416 Requested Range Not Satisfiable (status code) 6 974 A 975 Accept-Ranges header field 8 977 C 978 Content-Range header field 9 980 G 981 Grammar 982 Accept-Ranges 8 983 acceptable-ranges 8 984 byte-content-range-spec 9 985 byte-range-resp-spec 9 986 byte-range-set 12 987 byte-range-spec 12 988 byte-ranges-specifier 12 989 bytes-unit 5 990 Content-Range 9 991 first-byte-pos 12 992 If-Range 11 993 instance-length 9 994 last-byte-pos 12 995 other-range-unit 5 996 Range 13 997 range-unit 5 998 ranges-specifier 12 999 suffix-byte-range-spec 12 1000 suffix-length 12 1002 I 1003 If-Range header field 10 1005 M 1006 Media Type 1007 multipart/byteranges 17 1008 multipart/x-byteranges 19 1009 multipart/byteranges Media Type 17 1010 multipart/x-byteranges Media Type 19 1012 R 1013 Range header field 11 1015 Authors' Addresses 1017 Roy T. Fielding (editor) 1018 Adobe Systems Incorporated 1019 345 Park Ave 1020 San Jose, CA 95110 1021 USA 1023 EMail: fielding@gbiv.com 1024 URI: http://roy.gbiv.com/ 1025 Yves Lafon (editor) 1026 World Wide Web Consortium 1027 W3C / ERCIM 1028 2004, rte des Lucioles 1029 Sophia-Antipolis, AM 06902 1030 France 1032 EMail: ylafon@w3.org 1033 URI: http://www.raubacapeu.net/people/yves/ 1035 Julian F. Reschke (editor) 1036 greenbytes GmbH 1037 Hafenweg 16 1038 Muenster, NW 48155 1039 Germany 1041 EMail: julian.reschke@greenbytes.de 1042 URI: http://greenbytes.de/tech/webdav/