idnits 2.17.1 draft-ietf-httpbis-p5-range-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, 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 26, 2009) is 5286 days in the past. Is this intentional? 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-08 == Outdated reference: A later version (-20) exists of draft-ietf-httpbis-p3-payload-08 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-08 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-08 -- 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) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 4 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 Day Software 4 Obsoletes: 2616 (if approved) J. Gettys 5 Intended status: Standards Track One Laptop per Child 6 Expires: April 29, 2010 J. Mogul 7 HP 8 H. Frystyk 9 Microsoft 10 L. Masinter 11 Adobe Systems 12 P. Leach 13 Microsoft 14 T. Berners-Lee 15 W3C/MIT 16 Y. Lafon, Ed. 17 W3C 18 J. Reschke, Ed. 19 greenbytes 20 October 26, 2009 22 HTTP/1.1, part 5: Range Requests and Partial Responses 23 draft-ietf-httpbis-p5-range-08 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. This document may contain material 29 from IETF Documents or IETF Contributions published or made publicly 30 available before November 10, 2008. The person(s) controlling the 31 copyright in some of this material may not have granted the IETF 32 Trust the right to allow modifications of such material outside the 33 IETF Standards Process. Without obtaining an adequate license from 34 the person(s) controlling the copyright in such materials, this 35 document may not be modified outside the IETF Standards Process, and 36 derivative works of it may not be created outside the IETF Standards 37 Process, except to format it for publication as an RFC or to 38 translate it into languages other than English. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as Internet- 43 Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/ietf/1id-abstracts.txt. 52 The list of Internet-Draft Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html. 55 This Internet-Draft will expire on April 29, 2010. 57 Copyright Notice 59 Copyright (c) 2009 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents in effect on the date of 64 publication of this document (http://trustee.ietf.org/license-info). 65 Please review these documents carefully, as they describe your rights 66 and restrictions with respect to this document. 68 Abstract 70 The Hypertext Transfer Protocol (HTTP) is an application-level 71 protocol for distributed, collaborative, hypermedia information 72 systems. HTTP has been in use by the World Wide Web global 73 information initiative since 1990. This document is Part 5 of the 74 seven-part specification that defines the protocol referred to as 75 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines 76 range-specific requests and the rules for constructing and combining 77 responses to those requests. 79 Editorial Note (To be removed by RFC Editor) 81 Discussion of this draft should take place on the HTTPBIS working 82 group mailing list (ietf-http-wg@w3.org). The current issues list is 83 at and related 84 documents (including fancy diffs) can be found at 85 . 87 The changes in this draft are summarized in Appendix D.9. 89 Table of Contents 91 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 92 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 93 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 94 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5 95 1.2.2. ABNF Rules defined in other Parts of the 96 Specification . . . . . . . . . . . . . . . . . . . . 5 97 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 5 98 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5 99 3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 6 100 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 6 101 4. Combining Ranges . . . . . . . . . . . . . . . . . . . . . . . 7 102 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 7 103 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7 104 5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 8 105 5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 10 106 5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 11 107 5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 11 108 5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 13 109 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 110 6.1. Status Code Registration . . . . . . . . . . . . . . . . . 14 111 6.2. Message Header Registration . . . . . . . . . . . . . . . 14 112 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 113 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 114 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 115 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 116 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 117 Appendix A. Internet Media Type multipart/byteranges . . . . . . 16 118 Appendix B. Compatibility with Previous Versions . . . . . . . . 18 119 B.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 18 120 B.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 19 121 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 19 122 Appendix D. Change Log (to be removed by RFC Editor before 123 publication) . . . . . . . . . . . . . . . . . . . . 20 124 D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 20 125 D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 21 126 D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 21 127 D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 21 128 D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 21 129 D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 21 130 D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 22 131 D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 22 132 D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 22 133 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 136 1. Introduction 138 HTTP clients often encounter interrupted data transfers as a result 139 of cancelled requests or dropped connections. When a cache has 140 stored a partial representation, it is desirable to request the 141 remainder of that representation in a subsequent request rather than 142 transfer the entire representation. There are also a number of Web 143 applications that benefit from being able to request only a subset of 144 a larger representation, such as a single page of a very large 145 document or only part of an image to be rendered by a device with 146 limited local storage. 148 This document defines HTTP/1.1 range requests, partial responses, and 149 the multipart/byteranges media type. The protocol for range requests 150 is an OPTIONAL feature of HTTP, designed so resources or recipients 151 that do not implement this feature can respond as if it is a normal 152 GET request without impacting interoperability. Partial responses 153 are indicated by a distinct status code to not be mistaken for full 154 responses by intermediate caches that might not implement the 155 feature. 157 Although the HTTP range request mechanism is designed to allow for 158 extensible range types, this specification only defines requests for 159 byte ranges. 161 1.1. Requirements 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in [RFC2119]. 167 An implementation is not compliant if it fails to satisfy one or more 168 of the MUST or REQUIRED level requirements for the protocols it 169 implements. An implementation that satisfies all the MUST or 170 REQUIRED level and all the SHOULD level requirements for its 171 protocols is said to be "unconditionally compliant"; one that 172 satisfies all the MUST level requirements but not all the SHOULD 173 level requirements for its protocols is said to be "conditionally 174 compliant." 176 1.2. Syntax Notation 178 This specification uses the ABNF syntax defined in Section 1.2 of 179 [Part1] (which extends the syntax defined in [RFC5234] with a list 180 rule). Appendix C shows the collected ABNF, with the list rule 181 expanded. 183 The following core rules are included by reference, as defined in 185 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 186 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 187 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit 188 sequence of data), SP (space), VCHAR (any visible USASCII character), 189 and WSP (whitespace). 191 1.2.1. Core Rules 193 The core rules below are defined in Section 1.2.2 of [Part1]: 195 token = 196 OWS = 198 1.2.2. ABNF Rules defined in other Parts of the Specification 200 The ABNF rules below are defined in other parts: 202 HTTP-date = 204 entity-tag = 206 2. Range Units 208 HTTP/1.1 allows a client to request that only part (a range of) the 209 response entity be included within the response. HTTP/1.1 uses range 210 units in the Range (Section 5.4) and Content-Range (Section 5.2) 211 header fields. An entity can be broken down into subranges according 212 to various structural units. 214 range-unit = bytes-unit / other-range-unit 215 bytes-unit = "bytes" 216 other-range-unit = token 218 HTTP/1.1 has been designed to allow implementations of applications 219 that do not depend on knowledge of ranges. The only range unit 220 defined by HTTP/1.1 is "bytes". 222 If a range unit is not understood in a request, a server MUST ignore 223 the whole Range header (Section 5.4). If a range unit is not 224 understood in a response, an intermediary SHOULD pass the response to 225 the client; a client MUST fail. 227 3. Status Code Definitions 228 3.1. 206 Partial Content 230 The server has fulfilled the partial GET request for the resource. 231 The request MUST have included a Range header field (Section 5.4) 232 indicating the desired range, and MAY have included an If-Range 233 header field (Section 5.3) to make the request conditional. 235 The response MUST include the following header fields: 237 o Either a Content-Range header field (Section 5.2) indicating the 238 range included with this response, or a multipart/byteranges 239 Content-Type including Content-Range fields for each part. If a 240 Content-Length header field is present in the response, its value 241 MUST match the actual number of OCTETs transmitted in the message- 242 body. 244 o Date 246 o ETag and/or Content-Location, if the header would have been sent 247 in a 200 response to the same request 249 o Expires, Cache-Control, and/or Vary, if the field-value might 250 differ from that sent in any previous response for the same 251 variant 253 If the 206 response is the result of an If-Range request, the 254 response SHOULD NOT include other entity-headers. Otherwise, the 255 response MUST include all of the entity-headers that would have been 256 returned with a 200 (OK) response to the same request. 258 A cache MUST NOT combine a 206 response with other previously cached 259 content if the ETag or Last-Modified headers do not match exactly, 260 see Section 4. 262 A cache that does not support the Range and Content-Range headers 263 MUST NOT cache 206 (Partial Content) responses. Furthermore, if a 264 response uses a range unit that is not understood by the cache, then 265 it MUST NOT be cached either. 267 3.2. 416 Requested Range Not Satisfiable 269 A server SHOULD return a response with this status code if a request 270 included a Range request-header field (Section 5.4), and none of the 271 ranges-specifier values in this field overlap the current extent of 272 the selected resource, and the request did not include an If-Range 273 request-header field. (For byte-ranges, this means that the first- 274 byte-pos of all of the byte-range-spec values were greater than the 275 current length of the selected resource.) 276 When this status code is returned for a byte-range request, the 277 response SHOULD include a Content-Range entity-header field 278 specifying the current length of the selected resource (see 279 Section 5.2). This response MUST NOT use the multipart/byteranges 280 content-type. 282 4. Combining Ranges 284 A response might transfer only a subrange of an entity-body, either 285 the request included one or more Range specifications, or because a 286 connection was broken prematurely. After several such transfers, a 287 cache might have received several ranges of the same entity-body. 289 If a cache has a stored non-empty set of subranges for an entity, and 290 an incoming response transfers another subrange, the cache MAY 291 combine the new subrange with the existing set if both the following 292 conditions are met: 294 o Both the incoming response and the cache entry have a cache 295 validator. 297 o The two cache validators match using the strong comparison 298 function (see Section 4 of [Part4]). 300 If either requirement is not met, the cache MUST use only the most 301 recent partial response (based on the Date values transmitted with 302 every response, and using the incoming response if these values are 303 equal or missing), and MUST discard the other partial information. 305 5. Header Field Definitions 307 This section defines the syntax and semantics of HTTP/1.1 header 308 fields related to range requests and partial responses. 310 For entity-header fields, both sender and recipient refer to either 311 the client or the server, depending on who sends and who receives the 312 entity. 314 5.1. Accept-Ranges 316 The "Accept-Ranges" response-header field allows a resource to 317 indicate its acceptance of range requests. 319 Accept-Ranges = "Accept-Ranges" ":" OWS Accept-Ranges-v 320 Accept-Ranges-v = acceptable-ranges 321 acceptable-ranges = 1#range-unit / "none" 323 Origin servers that accept byte-range requests MAY send 325 Accept-Ranges: bytes 327 but are not required to do so. Clients MAY generate range requests 328 without having received this header for the resource involved. Range 329 units are defined in Section 2. 331 Servers that do not accept any kind of range request for a resource 332 MAY send 334 Accept-Ranges: none 336 to advise the client not to attempt a range request. 338 5.2. Content-Range 340 The "Content-Range" entity-header field is sent with a partial 341 entity-body to specify where in the full entity-body the partial body 342 should be applied. Range units are defined in Section 2. 344 Content-Range = "Content-Range" ":" OWS Content-Range-v 345 Content-Range-v = content-range-spec 347 content-range-spec = byte-content-range-spec 348 / other-content-range-spec 349 byte-content-range-spec = bytes-unit SP 350 byte-range-resp-spec "/" 351 ( instance-length / "*" ) 353 byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) 354 / "*" 356 instance-length = 1*DIGIT 358 other-content-range-spec = other-range-unit SP 359 other-range-resp-spec 360 other-range-resp-spec = *CHAR 362 The header SHOULD indicate the total length of the full entity-body, 363 unless this length is unknown or difficult to determine. The 364 asterisk "*" character means that the instance-length is unknown at 365 the time when the response was generated. 367 Unlike byte-ranges-specifier values (see Section 5.4.1), a byte- 368 range-resp-spec MUST only specify one range, and MUST contain 369 absolute byte positions for both the first and last byte of the 370 range. 372 A byte-content-range-spec with a byte-range-resp-spec whose last- 373 byte-pos value is less than its first-byte-pos value, or whose 374 instance-length value is less than or equal to its last-byte-pos 375 value, is invalid. The recipient of an invalid byte-content-range- 376 spec MUST ignore it and any content transferred along with it. 378 In the case of a byte range request: A server sending a response with 379 status code 416 (Requested range not satisfiable) SHOULD include a 380 Content-Range field with a byte-range-resp-spec of "*". The 381 instance-length specifies the current length of the selected 382 resource. A response with status code 206 (Partial Content) MUST NOT 383 include a Content-Range field with a byte-range-resp-spec of "*". 385 Examples of byte-content-range-spec values, assuming that the entity 386 contains a total of 1234 bytes: 388 o The first 500 bytes: 390 bytes 0-499/1234 392 o The second 500 bytes: 394 bytes 500-999/1234 396 o All except for the first 500 bytes: 398 bytes 500-1233/1234 400 o The last 500 bytes: 402 bytes 734-1233/1234 404 When an HTTP message includes the content of a single range (for 405 example, a response to a request for a single range, or to a request 406 for a set of ranges that overlap without any holes), this content is 407 transmitted with a Content-Range header, and a Content-Length header 408 showing the number of bytes actually transferred. For example, 410 HTTP/1.1 206 Partial Content 411 Date: Wed, 15 Nov 1995 06:25:24 GMT 412 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 413 Content-Range: bytes 21010-47021/47022 414 Content-Length: 26012 415 Content-Type: image/gif 417 When an HTTP message includes the content of multiple ranges (for 418 example, a response to a request for multiple non-overlapping 419 ranges), these are transmitted as a multipart message. The multipart 420 media type used for this purpose is "multipart/byteranges" as defined 421 in Appendix A. See Appendix B.1 for a compatibility issue. 423 A response to a request for a single range MUST NOT be sent using the 424 multipart/byteranges media type. A response to a request for 425 multiple ranges, whose result is a single range, MAY be sent as a 426 multipart/byteranges media type with one part. A client that cannot 427 decode a multipart/byteranges message MUST NOT ask for multiple 428 ranges in a single request. 430 When a client requests multiple ranges in one request, the server 431 SHOULD return them in the order that they appeared in the request. 433 If the server ignores a byte-range-spec because it is syntactically 434 invalid, the server SHOULD treat the request as if the invalid Range 435 header field did not exist. (Normally, this means return a 200 436 response containing the full entity). 438 If the server receives a request (other than one including an If- 439 Range request-header field) with an unsatisfiable Range request- 440 header field (that is, all of whose byte-range-spec values have a 441 first-byte-pos value greater than the current length of the selected 442 resource), it SHOULD return a response code of 416 (Requested range 443 not satisfiable) (Section 3.2). 445 Note: clients cannot depend on servers to send a 416 (Requested 446 range not satisfiable) response instead of a 200 (OK) response for 447 an unsatisfiable Range request-header, since not all servers 448 implement this request-header. 450 5.3. If-Range 452 If a client has a partial copy of an entity in its cache, and wishes 453 to have an up-to-date copy of the entire entity in its cache, it 454 could use the Range request-header with a conditional GET (using 455 either or both of If-Unmodified-Since and If-Match.) However, if the 456 condition fails because the entity has been modified, the client 457 would then have to make a second request to obtain the entire current 458 entity-body. 460 The "If-Range" request-header field allows a client to "short- 461 circuit" the second request. Informally, its meaning is `if the 462 entity is unchanged, send me the part(s) that I am missing; 463 otherwise, send me the entire new entity'. 465 If-Range = "If-Range" ":" OWS If-Range-v 466 If-Range-v = entity-tag / HTTP-date 468 If the client has no entity tag for an entity, but does have a Last- 469 Modified date, it MAY use that date in an If-Range header. (The 470 server can distinguish between a valid HTTP-date and any form of 471 entity-tag by examining no more than two characters.) The If-Range 472 header SHOULD only be used together with a Range header, and MUST be 473 ignored if the request does not include a Range header, or if the 474 server does not support the sub-range operation. 476 If the entity tag given in the If-Range header matches the current 477 cache validator for the entity, then the server SHOULD provide the 478 specified sub-range of the entity using a 206 (Partial Content) 479 response. If the cache validator does not match, then the server 480 SHOULD return the entire entity using a 200 (OK) response. 482 5.4. Range 484 5.4.1. Byte Ranges 486 Since all HTTP entities are represented in HTTP messages as sequences 487 of bytes, the concept of a byte range is meaningful for any HTTP 488 entity. (However, not all clients and servers need to support byte- 489 range operations.) 491 Byte range specifications in HTTP apply to the sequence of bytes in 492 the entity-body (not necessarily the same as the message-body). 494 A byte range operation MAY specify a single range of bytes, or a set 495 of ranges within a single entity. 497 byte-ranges-specifier = bytes-unit "=" byte-range-set 498 byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec ) 499 byte-range-spec = first-byte-pos "-" [ last-byte-pos ] 500 first-byte-pos = 1*DIGIT 501 last-byte-pos = 1*DIGIT 503 The first-byte-pos value in a byte-range-spec gives the byte-offset 504 of the first byte in a range. The last-byte-pos value gives the 505 byte-offset of the last byte in the range; that is, the byte 506 positions specified are inclusive. Byte offsets start at zero. 508 If the last-byte-pos value is present, it MUST be greater than or 509 equal to the first-byte-pos in that byte-range-spec, or the byte- 510 range-spec is syntactically invalid. The recipient of a byte-range- 511 set that includes one or more syntactically invalid byte-range-spec 512 values MUST ignore the header field that includes that byte-range- 513 set. 515 If the last-byte-pos value is absent, or if the value is greater than 516 or equal to the current length of the entity-body, last-byte-pos is 517 taken to be equal to one less than the current length of the entity- 518 body in bytes. 520 By its choice of last-byte-pos, a client can limit the number of 521 bytes retrieved without knowing the size of the entity. 523 suffix-byte-range-spec = "-" suffix-length 524 suffix-length = 1*DIGIT 526 A suffix-byte-range-spec is used to specify the suffix of the entity- 527 body, of a length given by the suffix-length value. (That is, this 528 form specifies the last N bytes of an entity-body.) If the entity is 529 shorter than the specified suffix-length, the entire entity-body is 530 used. 532 If a syntactically valid byte-range-set includes at least one byte- 533 range-spec whose first-byte-pos is less than the current length of 534 the entity-body, or at least one suffix-byte-range-spec with a non- 535 zero suffix-length, then the byte-range-set is satisfiable. 536 Otherwise, the byte-range-set is unsatisfiable. If the byte-range- 537 set is unsatisfiable, the server SHOULD return a response with a 538 status of 416 (Requested range not satisfiable). Otherwise, the 539 server SHOULD return a response with a status of 206 (Partial 540 Content) containing the satisfiable ranges of the entity-body. 542 Examples of byte-ranges-specifier values (assuming an entity-body of 543 length 10000): 545 o The first 500 bytes (byte offsets 0-499, inclusive): 547 bytes=0-499 549 o The second 500 bytes (byte offsets 500-999, inclusive): 551 bytes=500-999 553 o The final 500 bytes (byte offsets 9500-9999, inclusive): 555 bytes=-500 557 Or: 559 bytes=9500- 561 o The first and last bytes only (bytes 0 and 9999): 563 bytes=0-0,-1 565 o Several legal but not canonical specifications of the second 500 566 bytes (byte offsets 500-999, inclusive): 568 bytes=500-600,601-999 569 bytes=500-700,601-999 571 5.4.2. Range Retrieval Requests 573 The "Range" request-header field defines the GET method (conditional 574 or not) to request one or more sub-ranges of the response entity- 575 body, instead of the entire entity body. 577 Range = "Range" ":" OWS Range-v 578 Range-v = byte-ranges-specifier 579 / other-ranges-specifier 580 other-ranges-specifier = other-range-unit "=" other-range-set 581 other-range-set = 1*CHAR 583 A server MAY ignore the Range header. However, HTTP/1.1 origin 584 servers and intermediate caches ought to support byte ranges when 585 possible, since Range supports efficient recovery from partially 586 failed transfers, and supports efficient partial retrieval of large 587 entities. 589 If the server supports the Range header and the specified range or 590 ranges are appropriate for the entity: 592 o The presence of a Range header in an unconditional GET modifies 593 what is returned if the GET is otherwise successful. In other 594 words, the response carries a status code of 206 (Partial Content) 595 instead of 200 (OK). 597 o The presence of a Range header in a conditional GET (a request 598 using one or both of If-Modified-Since and If-None-Match, or one 599 or both of If-Unmodified-Since and If-Match) modifies what is 600 returned if the GET is otherwise successful and the condition is 601 true. It does not affect the 304 (Not Modified) response returned 602 if the conditional is false. 604 In some cases, it might be more appropriate to use the If-Range 605 header (see Section 5.3) in addition to the Range header. 607 If a proxy that supports ranges receives a Range request, forwards 608 the request to an inbound server, and receives an entire entity in 609 reply, it SHOULD only return the requested range to its client. It 610 SHOULD store the entire received response in its cache if that is 611 consistent with its cache allocation policies. 613 6. IANA Considerations 615 6.1. Status Code Registration 617 The HTTP Status Code Registry located at 618 should be updated 619 with the registrations below: 621 +-------+---------------------------------+-------------+ 622 | Value | Description | Reference | 623 +-------+---------------------------------+-------------+ 624 | 206 | Partial Content | Section 3.1 | 625 | 416 | Requested Range Not Satisfiable | Section 3.2 | 626 +-------+---------------------------------+-------------+ 628 6.2. Message Header Registration 630 The Message Header Registry located at should be 632 updated with the permanent registrations below (see [RFC3864]): 634 +-------------------+----------+----------+-------------+ 635 | Header Field Name | Protocol | Status | Reference | 636 +-------------------+----------+----------+-------------+ 637 | Accept-Ranges | http | standard | Section 5.1 | 638 | Content-Range | http | standard | Section 5.2 | 639 | If-Range | http | standard | Section 5.3 | 640 | Range | http | standard | Section 5.4 | 641 +-------------------+----------+----------+-------------+ 643 The change controller is: "IETF (iesg@ietf.org) - Internet 644 Engineering Task Force". 646 7. Security Considerations 648 No additional security considerations have been identified beyond 649 those applicable to HTTP in general [Part1]. 651 8. Acknowledgments 653 Most of the specification of ranges is based on work originally done 654 by Ari Luotonen and John Franks, with additional input from Steve 655 Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin 656 Hamilton, Koen Holtman, Shel Kaplan, Paul Leach, Alex Lopez-Ortiz, 657 Larry Masinter, Jeff Mogul, Lou Montulli, David W. Morris, Luigi 658 Rizzo, and Bill Weihl. 660 9. References 662 9.1. Normative References 664 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 665 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 666 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, 667 and Message Parsing", draft-ietf-httpbis-p1-messaging-08 668 (work in progress), October 2009. 670 [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 671 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 672 and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload 673 and Content Negotiation", draft-ietf-httpbis-p3-payload-08 674 (work in progress), October 2009. 676 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 677 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 678 and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional 679 Requests", draft-ietf-httpbis-p4-conditional-08 (work in 680 progress), October 2009. 682 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 683 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 684 Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part 685 6: Caching", draft-ietf-httpbis-p6-cache-08 (work in 686 progress), October 2009. 688 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 689 Extensions (MIME) Part Two: Media Types", RFC 2046, 690 November 1996. 692 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 693 Requirement Levels", BCP 14, RFC 2119, March 1997. 695 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 696 Specifications: ABNF", STD 68, RFC 5234, January 2008. 698 9.2. Informative References 700 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 701 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 702 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 704 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 705 Procedures for Message Header Fields", BCP 90, RFC 3864, 706 September 2004. 708 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 709 Registration Procedures", BCP 13, RFC 4288, December 2005. 711 Appendix A. Internet Media Type multipart/byteranges 713 When an HTTP 206 (Partial Content) response message includes the 714 content of multiple ranges (a response to a request for multiple non- 715 overlapping ranges), these are transmitted as a multipart message- 716 body ([RFC2046], Section 5.1). The media type for this purpose is 717 called "multipart/byteranges". The following is to be registered 718 with IANA [RFC4288]. 720 Note: Despite the name "multipart/byteranges" is not limited to 721 the byte ranges only. 723 The multipart/byteranges media type includes one or more parts, each 724 with its own Content-Type and Content-Range fields. The required 725 boundary parameter specifies the boundary string used to separate 726 each body-part. 728 Type name: multipart 730 Subtype name: byteranges 732 Required parameters: boundary 734 Optional parameters: none 736 Encoding considerations: only "7bit", "8bit", or "binary" are 737 permitted 739 Security considerations: none 741 Interoperability considerations: none 743 Published specification: This specification (see Appendix A). 745 Applications that use this media type: 747 Additional information: 749 Magic number(s): none 751 File extension(s): none 752 Macintosh file type code(s): none 754 Person and email address to contact for further information: See 755 Authors Section. 757 Intended usage: COMMON 759 Restrictions on usage: none 761 Author/Change controller: IESG 763 For example: 765 HTTP/1.1 206 Partial Content 766 Date: Wed, 15 Nov 1995 06:25:24 GMT 767 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 768 Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES 770 --THIS_STRING_SEPARATES 771 Content-type: application/pdf 772 Content-range: bytes 500-999/8000 774 ...the first range... 775 --THIS_STRING_SEPARATES 776 Content-type: application/pdf 777 Content-range: bytes 7000-7999/8000 779 ...the second range 780 --THIS_STRING_SEPARATES-- 782 Other example: 784 HTTP/1.1 206 Partial Content 785 Date: Tue, 14 Nov 1995 06:25:24 GMT 786 Last-Modified: Tue, 14 July 04:58:08 GMT 787 Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES 789 --THIS_STRING_SEPARATES 790 Content-type: video/example 791 Content-range: exampleunit 1.2-4.3/25 793 ...the first range... 794 --THIS_STRING_SEPARATES 795 Content-type: video/example 796 Content-range: exampleunit 11.2-14.3/25 798 ...the second range 799 --THIS_STRING_SEPARATES-- 801 Notes: 803 1. Additional CRLFs may precede the first boundary string in the 804 entity. 806 2. Although [RFC2046] permits the boundary string to be quoted, some 807 existing implementations handle a quoted boundary string 808 incorrectly. 810 3. A number of browsers and servers were coded to an early draft of 811 the byteranges specification to use a media type of multipart/ 812 x-byteranges, which is almost, but not quite compatible with the 813 version documented in HTTP/1.1. 815 Appendix B. Compatibility with Previous Versions 817 B.1. Changes from RFC 2068 819 Transfer-coding and message lengths all interact in ways that 820 required fixing exactly when chunked encoding is used (to allow for 821 transfer encoding that may not be self delimiting); it was important 822 to straighten out exactly how message lengths are computed. 823 (Section 5.2, see also [Part1], [Part3] and [Part6]) 825 There are situations where a server (especially a proxy) does not 826 know the full length of a response but is capable of serving a 827 byterange request. We therefore need a mechanism to allow byteranges 828 with a content-range not indicating the full length of the message. 830 (Section 5.2) 832 Range request responses would become very verbose if all meta-data 833 were always returned; by allowing the server to only send needed 834 headers in a 206 response, this problem can be avoided. (Section 3.1 835 and 5.3) 837 Fix problem with unsatisfiable range requests; there are two cases: 838 syntactic problems, and range doesn't exist in the document. The 416 839 status code was needed to resolve this ambiguity needed to indicate 840 an error for a byte range request that falls outside of the actual 841 contents of a document. (Section 3.2, 5.2) 843 B.2. Changes from RFC 2616 845 Clarify that it is not ok to use a weak cache validator in a 206 846 response. (Section 3.1) 848 Clarify that multipart/byteranges can consist of a single part. 849 (Appendix A) 851 Appendix C. Collected ABNF 853 Accept-Ranges = "Accept-Ranges:" OWS Accept-Ranges-v 854 Accept-Ranges-v = acceptable-ranges 856 Content-Range = "Content-Range:" OWS Content-Range-v 857 Content-Range-v = content-range-spec 859 HTTP-date = 861 If-Range = "If-Range:" OWS If-Range-v 862 If-Range-v = entity-tag / HTTP-date 864 OWS = 866 Range = "Range:" OWS Range-v 867 Range-v = byte-ranges-specifier / other-ranges-specifier 869 acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS 870 range-unit ] ) ) / "none" 872 byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" ( 873 instance-length / "*" ) 874 byte-range-resp-spec = ( first-byte-pos "-" last-byte-pos ) / "*" 875 byte-range-set = ( *( "," OWS ) byte-range-spec ) / ( 876 suffix-byte-range-spec *( OWS "," [ ( OWS byte-range-spec ) / 877 suffix-byte-range-spec ] ) ) 878 byte-range-spec = first-byte-pos "-" [ last-byte-pos ] 879 byte-ranges-specifier = bytes-unit "=" byte-range-set 880 bytes-unit = "bytes" 882 content-range-spec = byte-content-range-spec / 883 other-content-range-spec 885 entity-tag = 887 first-byte-pos = 1*DIGIT 889 instance-length = 1*DIGIT 891 last-byte-pos = 1*DIGIT 893 other-content-range-spec = other-range-unit SP other-range-resp-spec 894 other-range-resp-spec = *CHAR 895 other-range-set = 1*CHAR 896 other-range-unit = token 897 other-ranges-specifier = other-range-unit "=" other-range-set 899 range-unit = bytes-unit / other-range-unit 901 suffix-byte-range-spec = "-" suffix-length 902 suffix-length = 1*DIGIT 904 token = 906 ABNF diagnostics: 908 ; Accept-Ranges defined but not used 909 ; Content-Range defined but not used 910 ; If-Range defined but not used 911 ; Range defined but not used 913 Appendix D. Change Log (to be removed by RFC Editor before publication) 915 D.1. Since RFC2616 917 Extracted relevant partitions from [RFC2616]. 919 D.2. Since draft-ietf-httpbis-p5-range-00 921 Closed issues: 923 o : "Cache 924 validators in 206 responses" 925 () 927 o : "Normative and 928 Informative references" 930 o : "Normative up- 931 to-date references" 933 D.3. Since draft-ietf-httpbis-p5-range-01 935 Closed issues: 937 o : "Updating to 938 RFC4288" 940 Ongoing work on ABNF conversion 941 (): 943 o Add explicit references to BNF syntax and rules imported from 944 other parts of the specification. 946 D.4. Since draft-ietf-httpbis-p5-range-02 948 Ongoing work on IANA Message Header Registration 949 (): 951 o Reference RFC 3984, and update header registrations for headers 952 defined in this document. 954 D.5. Since draft-ietf-httpbis-p5-range-03 956 D.6. Since draft-ietf-httpbis-p5-range-04 958 Closed issues: 960 o : "multipart/ 961 byteranges minimum number of parts" 963 Ongoing work on ABNF conversion 964 (): 966 o Use "/" instead of "|" for alternatives. 968 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 969 whitespace ("OWS") and required whitespace ("RWS"). 971 o Rewrite ABNFs to spell out whitespace rules, factor out header 972 value format definitions. 974 D.7. Since draft-ietf-httpbis-p5-range-05 976 Closed issues: 978 o : "State base 979 for *-byte-pos and suffix-length" 981 Ongoing work on Custom Ranges 982 (): 984 o Remove bias in favor of byte ranges; allow custom ranges in ABNF. 986 Final work on ABNF conversion 987 (): 989 o Add appendix containing collected and expanded ABNF, reorganize 990 ABNF introduction. 992 D.8. Since draft-ietf-httpbis-p5-range-06 994 Closed issues: 996 o : "base for 997 numeric protocol elements" 999 D.9. Since draft-ietf-httpbis-p5-range-07 1001 Closed issues: 1003 o Fixed discrepancy in the If-Range definition about allowed 1004 validators. 1006 o : 1007 "multipart/byteranges for custom range units" 1009 o : "range 1010 unit missing from other-ranges-specifier in Range header" 1012 o : "move IANA 1013 registrations for optional status codes" 1015 Index 1017 2 1018 206 Partial Content (status code) 6 1020 4 1021 416 Requested Range Not Satisfiable (status code) 6 1023 A 1024 Accept-Ranges header 7 1026 C 1027 Content-Range header 8 1029 G 1030 Grammar 1031 Accept-Ranges 7 1032 Accept-Ranges-v 7 1033 acceptable-ranges 7 1034 byte-content-range-spec 8 1035 byte-range-resp-spec 8 1036 byte-range-set 11 1037 byte-range-spec 11 1038 byte-ranges-specifier 11 1039 bytes-unit 5 1040 Content-Range 8 1041 content-range-spec 8 1042 Content-Range-v 8 1043 first-byte-pos 11 1044 If-Range 10 1045 If-Range-v 10 1046 instance-length 8 1047 last-byte-pos 11 1048 other-range-unit 5 1049 Range 13 1050 range-unit 5 1051 ranges-specifier 11 1052 suffix-byte-range-spec 12 1053 suffix-length 12 1055 H 1056 Headers 1057 Accept-Ranges 7 1058 Content-Range 8 1059 If-Range 10 1060 Range 11 1062 I 1063 If-Range header 10 1065 M 1066 Media Type 1067 multipart/byteranges 16 1068 multipart/x-byteranges 18 1069 multipart/byteranges Media Type 16 1070 multipart/x-byteranges Media Type 18 1072 R 1073 Range header 11 1075 S 1076 Status Codes 1077 206 Partial Content 6 1078 416 Requested Range Not Satisfiable 6 1080 Authors' Addresses 1082 Roy T. Fielding (editor) 1083 Day Software 1084 23 Corporate Plaza DR, Suite 280 1085 Newport Beach, CA 92660 1086 USA 1088 Phone: +1-949-706-5300 1089 Fax: +1-949-706-5305 1090 Email: fielding@gbiv.com 1091 URI: http://roy.gbiv.com/ 1093 Jim Gettys 1094 One Laptop per Child 1095 21 Oak Knoll Road 1096 Carlisle, MA 01741 1097 USA 1099 Email: jg@laptop.org 1100 URI: http://www.laptop.org/ 1101 Jeffrey C. Mogul 1102 Hewlett-Packard Company 1103 HP Labs, Large Scale Systems Group 1104 1501 Page Mill Road, MS 1177 1105 Palo Alto, CA 94304 1106 USA 1108 Email: JeffMogul@acm.org 1110 Henrik Frystyk Nielsen 1111 Microsoft Corporation 1112 1 Microsoft Way 1113 Redmond, WA 98052 1114 USA 1116 Email: henrikn@microsoft.com 1118 Larry Masinter 1119 Adobe Systems, Incorporated 1120 345 Park Ave 1121 San Jose, CA 95110 1122 USA 1124 Email: LMM@acm.org 1125 URI: http://larry.masinter.net/ 1127 Paul J. Leach 1128 Microsoft Corporation 1129 1 Microsoft Way 1130 Redmond, WA 98052 1132 Email: paulle@microsoft.com 1134 Tim Berners-Lee 1135 World Wide Web Consortium 1136 MIT Computer Science and Artificial Intelligence Laboratory 1137 The Stata Center, Building 32 1138 32 Vassar Street 1139 Cambridge, MA 02139 1140 USA 1142 Email: timbl@w3.org 1143 URI: http://www.w3.org/People/Berners-Lee/ 1144 Yves Lafon (editor) 1145 World Wide Web Consortium 1146 W3C / ERCIM 1147 2004, rte des Lucioles 1148 Sophia-Antipolis, AM 06902 1149 France 1151 Email: ylafon@w3.org 1152 URI: http://www.raubacapeu.net/people/yves/ 1154 Julian F. Reschke (editor) 1155 greenbytes GmbH 1156 Hafenweg 16 1157 Muenster, NW 48155 1158 Germany 1160 Phone: +49 251 2807760 1161 Fax: +49 251 2807761 1162 Email: julian.reschke@greenbytes.de 1163 URI: http://greenbytes.de/tech/webdav/