idnits 2.17.1 draft-ietf-httpbis-p5-range-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 30. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 869. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 880. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 887. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 893. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 12, 2008) is 5948 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-01 == Outdated reference: A later version (-20) exists of draft-ietf-httpbis-p3-payload-01 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-01 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-01 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network 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: July 15, 2008 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 January 12, 2008 22 HTTP/1.1, part 5: Range Requests and Partial Responses 23 draft-ietf-httpbis-p5-range-01 25 Status of this Memo 27 By submitting this Internet-Draft, each author represents that any 28 applicable patent or other IPR claims of which he or she is aware 29 have been or will be disclosed, and any of which he or she becomes 30 aware will be disclosed, in accordance with Section 6 of BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on July 15, 2008. 50 Copyright Notice 52 Copyright (C) The IETF Trust (2008). 54 Abstract 56 The Hypertext Transfer Protocol (HTTP) is an application-level 57 protocol for distributed, collaborative, hypermedia information 58 systems. HTTP has been in use by the World Wide Web global 59 information initiative since 1990. This document is Part 5 of the 60 seven-part specification that defines the protocol referred to as 61 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines 62 range-specific requests and the rules for constructing and combining 63 responses to those requests. 65 Editorial Note (To be removed by RFC Editor) 67 Discussion of this draft should take place on the HTTPBIS working 68 group mailing list (ietf-http-wg@w3.org). The current issues list is 69 at and related 70 documents (including fancy diffs) can be found at 71 . 73 This draft incorporates those issue resolutions that were either 74 collected in the original RFC2616 errata list 75 (), or which were agreed upon on the 76 mailing list between October 2006 and November 2007 (as published in 77 "draft-lafon-rfc2616bis-03"). 79 Table of Contents 81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 82 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 83 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 4 84 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5 85 3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 5 86 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 6 87 4. Combining Byte Ranges . . . . . . . . . . . . . . . . . . . . 6 88 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 6 89 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7 90 5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 7 91 5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 9 92 5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 10 93 5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 10 94 5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 12 95 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 97 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 98 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 99 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 100 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 101 Appendix A. Internet Media Type multipart/byteranges . . . . . . 14 102 Appendix B. Compatibility with Previous Versions . . . . . . . . 15 103 B.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 15 104 B.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 16 105 Appendix C. Change Log (to be removed by RFC Editor before 106 publication) . . . . . . . . . . . . . . . . . . . . 16 107 C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 16 108 C.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 16 109 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 111 Intellectual Property and Copyright Statements . . . . . . . . . . 21 113 1. Introduction 115 HTTP clients often encounter interrupted data transfers as a result 116 of cancelled requests or dropped connections. When a cache has 117 stored a partial representation, it is desirable to request the 118 remainder of that representation in a subsequent request rather than 119 transfer the entire representation. There are also a number of Web 120 applications that benefit from being able to request only a subset of 121 a larger representation, such as a single page of a very large 122 document or only part of an image to be rendered by a device with 123 limited local storage. 125 This document defines HTTP/1.1 range requests, partial responses, and 126 the multipart/byteranges media type. The protocol for range requests 127 is an OPTIONAL feature of HTTP, designed so resources or recipients 128 that do not implement this feature can respond as if it is a normal 129 GET request without impacting interoperability. Partial responses 130 are indicated by a distinct status code to not be mistaken for full 131 responses by intermediate caches that might not implement the 132 feature. 134 Although the HTTP range request mechanism is designed to allow for 135 extensible range types, this specification only defines requests for 136 byte ranges. 138 1.1. Requirements 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 An implementation is not compliant if it fails to satisfy one or more 145 of the MUST or REQUIRED level requirements for the protocols it 146 implements. An implementation that satisfies all the MUST or 147 REQUIRED level and all the SHOULD level requirements for its 148 protocols is said to be "unconditionally compliant"; one that 149 satisfies all the MUST level requirements but not all the SHOULD 150 level requirements for its protocols is said to be "conditionally 151 compliant." 153 2. Range Units 155 HTTP/1.1 allows a client to request that only part (a range of) the 156 response entity be included within the response. HTTP/1.1 uses range 157 units in the Range (Section 5.4) and Content-Range (Section 5.2) 158 header fields. An entity can be broken down into subranges according 159 to various structural units. 161 range-unit = bytes-unit | other-range-unit 162 bytes-unit = "bytes" 163 other-range-unit = token 165 The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 166 implementations MAY ignore ranges specified using other units. 168 HTTP/1.1 has been designed to allow implementations of applications 169 that do not depend on knowledge of ranges. 171 3. Status Code Definitions 173 3.1. 206 Partial Content 175 The server has fulfilled the partial GET request for the resource. 176 The request MUST have included a Range header field (Section 5.4) 177 indicating the desired range, and MAY have included an If-Range 178 header field (Section 5.3) to make the request conditional. 180 The response MUST include the following header fields: 182 o Either a Content-Range header field (Section 5.2) indicating the 183 range included with this response, or a multipart/byteranges 184 Content-Type including Content-Range fields for each part. If a 185 Content-Length header field is present in the response, its value 186 MUST match the actual number of OCTETs transmitted in the message- 187 body. 189 o Date 191 o ETag and/or Content-Location, if the header would have been sent 192 in a 200 response to the same request 194 o Expires, Cache-Control, and/or Vary, if the field-value might 195 differ from that sent in any previous response for the same 196 variant 198 If the 206 response is the result of an If-Range request, the 199 response SHOULD NOT include other entity-headers. Otherwise, the 200 response MUST include all of the entity-headers that would have been 201 returned with a 200 (OK) response to the same request. 203 A cache MUST NOT combine a 206 response with other previously cached 204 content if the ETag or Last-Modified headers do not match exactly, 205 see Section 4. 207 A cache that does not support the Range and Content-Range headers 208 MUST NOT cache 206 (Partial Content) responses. 210 3.2. 416 Requested Range Not Satisfiable 212 A server SHOULD return a response with this status code if a request 213 included a Range request-header field (Section 5.4), and none of the 214 range-specifier values in this field overlap the current extent of 215 the selected resource, and the request did not include an If-Range 216 request-header field. (For byte-ranges, this means that the first- 217 byte-pos of all of the byte-range-spec values were greater than the 218 current length of the selected resource.) 220 When this status code is returned for a byte-range request, the 221 response SHOULD include a Content-Range entity-header field 222 specifying the current length of the selected resource (see 223 Section 5.2). This response MUST NOT use the multipart/byteranges 224 content-type. 226 4. Combining Byte Ranges 228 A response might transfer only a subrange of the bytes of an entity- 229 body, either because the request included one or more Range 230 specifications, or because a connection was broken prematurely. 231 After several such transfers, a cache might have received several 232 ranges of the same entity-body. 234 If a cache has a stored non-empty set of subranges for an entity, and 235 an incoming response transfers another subrange, the cache MAY 236 combine the new subrange with the existing set if both the following 237 conditions are met: 239 o Both the incoming response and the cache entry have a cache 240 validator. 242 o The two cache validators match using the strong comparison 243 function (see Section 4 of [Part4]). 245 If either requirement is not met, the cache MUST use only the most 246 recent partial response (based on the Date values transmitted with 247 every response, and using the incoming response if these values are 248 equal or missing), and MUST discard the other partial information. 250 5. Header Field Definitions 252 This section defines the syntax and semantics of HTTP/1.1 header 253 fields related to range requests and partial responses. 255 For entity-header fields, both sender and recipient refer to either 256 the client or the server, depending on who sends and who receives the 257 entity. 259 5.1. Accept-Ranges 261 The Accept-Ranges response-header field allows the server to indicate 262 its acceptance of range requests for a resource: 264 Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges 265 acceptable-ranges = 1#range-unit | "none" 267 Origin servers that accept byte-range requests MAY send 269 Accept-Ranges: bytes 271 but are not required to do so. Clients MAY generate byte-range 272 requests without having received this header for the resource 273 involved. Range units are defined in Section 2. 275 Servers that do not accept any kind of range request for a resource 276 MAY send 278 Accept-Ranges: none 280 to advise the client not to attempt a range request. 282 5.2. Content-Range 284 The Content-Range entity-header is sent with a partial entity-body to 285 specify where in the full entity-body the partial body should be 286 applied. Range units are defined in Section 2. 288 Content-Range = "Content-Range" ":" content-range-spec 290 content-range-spec = byte-content-range-spec 291 byte-content-range-spec = bytes-unit SP 292 byte-range-resp-spec "/" 293 ( instance-length | "*" ) 295 byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) 296 | "*" 297 instance-length = 1*DIGIT 299 The header SHOULD indicate the total length of the full entity-body, 300 unless this length is unknown or difficult to determine. The 301 asterisk "*" character means that the instance-length is unknown at 302 the time when the response was generated. 304 Unlike byte-ranges-specifier values (see Section 5.4.1), a byte- 305 range-resp-spec MUST only specify one range, and MUST contain 306 absolute byte positions for both the first and last byte of the 307 range. 309 A byte-content-range-spec with a byte-range-resp-spec whose last- 310 byte-pos value is less than its first-byte-pos value, or whose 311 instance-length value is less than or equal to its last-byte-pos 312 value, is invalid. The recipient of an invalid byte-content-range- 313 spec MUST ignore it and any content transferred along with it. 315 A server sending a response with status code 416 (Requested range not 316 satisfiable) SHOULD include a Content-Range field with a byte-range- 317 resp-spec of "*". The instance-length specifies the current length 318 of the selected resource. A response with status code 206 (Partial 319 Content) MUST NOT include a Content-Range field with a byte-range- 320 resp-spec of "*". 322 Examples of byte-content-range-spec values, assuming that the entity 323 contains a total of 1234 bytes: 325 o The first 500 bytes: 327 bytes 0-499/1234 329 o The second 500 bytes: 331 bytes 500-999/1234 333 o All except for the first 500 bytes: 335 bytes 500-1233/1234 337 o The last 500 bytes: 339 bytes 734-1233/1234 341 When an HTTP message includes the content of a single range (for 342 example, a response to a request for a single range, or to a request 343 for a set of ranges that overlap without any holes), this content is 344 transmitted with a Content-Range header, and a Content-Length header 345 showing the number of bytes actually transferred. For example, 347 HTTP/1.1 206 Partial Content 348 Date: Wed, 15 Nov 1995 06:25:24 GMT 349 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 350 Content-Range: bytes 21010-47021/47022 351 Content-Length: 26012 352 Content-Type: image/gif 354 When an HTTP message includes the content of multiple ranges (for 355 example, a response to a request for multiple non-overlapping 356 ranges), these are transmitted as a multipart message. The multipart 357 media type used for this purpose is "multipart/byteranges" as defined 358 in Appendix A. See Appendix B.1 for a compatibility issue. 360 A response to a request for a single range MUST NOT be sent using the 361 multipart/byteranges media type. A response to a request for 362 multiple ranges, whose result is a single range, MAY be sent as a 363 multipart/byteranges media type with one part. A client that cannot 364 decode a multipart/byteranges message MUST NOT ask for multiple byte- 365 ranges in a single request. 367 When a client requests multiple byte-ranges in one request, the 368 server SHOULD return them in the order that they appeared in the 369 request. 371 If the server ignores a byte-range-spec because it is syntactically 372 invalid, the server SHOULD treat the request as if the invalid Range 373 header field did not exist. (Normally, this means return a 200 374 response containing the full entity). 376 If the server receives a request (other than one including an If- 377 Range request-header field) with an unsatisfiable Range request- 378 header field (that is, all of whose byte-range-spec values have a 379 first-byte-pos value greater than the current length of the selected 380 resource), it SHOULD return a response code of 416 (Requested range 381 not satisfiable) (Section 3.2). 383 Note: clients cannot depend on servers to send a 416 (Requested 384 range not satisfiable) response instead of a 200 (OK) response for 385 an unsatisfiable Range request-header, since not all servers 386 implement this request-header. 388 5.3. If-Range 390 If a client has a partial copy of an entity in its cache, and wishes 391 to have an up-to-date copy of the entire entity in its cache, it 392 could use the Range request-header with a conditional GET (using 393 either or both of If-Unmodified-Since and If-Match.) However, if the 394 condition fails because the entity has been modified, the client 395 would then have to make a second request to obtain the entire current 396 entity-body. 398 The If-Range header allows a client to "short-circuit" the second 399 request. Informally, its meaning is `if the entity is unchanged, 400 send me the part(s) that I am missing; otherwise, send me the entire 401 new entity'. 403 If-Range = "If-Range" ":" ( entity-tag | HTTP-date ) 405 If the client has no entity tag for an entity, but does have a Last- 406 Modified date, it MAY use that date in an If-Range header. (The 407 server can distinguish between a valid HTTP-date and any form of 408 entity-tag by examining no more than two characters.) The If-Range 409 header SHOULD only be used together with a Range header, and MUST be 410 ignored if the request does not include a Range header, or if the 411 server does not support the sub-range operation. 413 If the entity tag given in the If-Range header matches the current 414 entity tag for the entity, then the server SHOULD provide the 415 specified sub-range of the entity using a 206 (Partial Content) 416 response. If the entity tag does not match, then the server SHOULD 417 return the entire entity using a 200 (OK) response. 419 5.4. Range 421 5.4.1. Byte Ranges 423 Since all HTTP entities are represented in HTTP messages as sequences 424 of bytes, the concept of a byte range is meaningful for any HTTP 425 entity. (However, not all clients and servers need to support byte- 426 range operations.) 428 Byte range specifications in HTTP apply to the sequence of bytes in 429 the entity-body (not necessarily the same as the message-body). 431 A byte range operation MAY specify a single range of bytes, or a set 432 of ranges within a single entity. 434 ranges-specifier = byte-ranges-specifier 435 byte-ranges-specifier = bytes-unit "=" byte-range-set 436 byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec ) 437 byte-range-spec = first-byte-pos "-" [last-byte-pos] 438 first-byte-pos = 1*DIGIT 439 last-byte-pos = 1*DIGIT 441 The first-byte-pos value in a byte-range-spec gives the byte-offset 442 of the first byte in a range. The last-byte-pos value gives the 443 byte-offset of the last byte in the range; that is, the byte 444 positions specified are inclusive. Byte offsets start at zero. 446 If the last-byte-pos value is present, it MUST be greater than or 447 equal to the first-byte-pos in that byte-range-spec, or the byte- 448 range-spec is syntactically invalid. The recipient of a byte-range- 449 set that includes one or more syntactically invalid byte-range-spec 450 values MUST ignore the header field that includes that byte-range- 451 set. 453 If the last-byte-pos value is absent, or if the value is greater than 454 or equal to the current length of the entity-body, last-byte-pos is 455 taken to be equal to one less than the current length of the entity- 456 body in bytes. 458 By its choice of last-byte-pos, a client can limit the number of 459 bytes retrieved without knowing the size of the entity. 461 suffix-byte-range-spec = "-" suffix-length 462 suffix-length = 1*DIGIT 464 A suffix-byte-range-spec is used to specify the suffix of the entity- 465 body, of a length given by the suffix-length value. (That is, this 466 form specifies the last N bytes of an entity-body.) If the entity is 467 shorter than the specified suffix-length, the entire entity-body is 468 used. 470 If a syntactically valid byte-range-set includes at least one byte- 471 range-spec whose first-byte-pos is less than the current length of 472 the entity-body, or at least one suffix-byte-range-spec with a non- 473 zero suffix-length, then the byte-range-set is satisfiable. 474 Otherwise, the byte-range-set is unsatisfiable. If the byte-range- 475 set is unsatisfiable, the server SHOULD return a response with a 476 status of 416 (Requested range not satisfiable). Otherwise, the 477 server SHOULD return a response with a status of 206 (Partial 478 Content) containing the satisfiable ranges of the entity-body. 480 Examples of byte-ranges-specifier values (assuming an entity-body of 481 length 10000): 483 o The first 500 bytes (byte offsets 0-499, inclusive): bytes=0-499 485 o The second 500 bytes (byte offsets 500-999, inclusive): bytes=500- 486 999 488 o The final 500 bytes (byte offsets 9500-9999, inclusive): bytes=- 489 500 491 o Or bytes=9500- 493 o The first and last bytes only (bytes 0 and 9999): bytes=0-0,-1 494 o Several legal but not canonical specifications of the second 500 495 bytes (byte offsets 500-999, inclusive): 496 bytes=500-600,601-999 497 bytes=500-700,601-999 499 5.4.2. Range Retrieval Requests 501 HTTP retrieval requests using conditional or unconditional GET 502 methods MAY request one or more sub-ranges of the entity, instead of 503 the entire entity, using the Range request header, which applies to 504 the entity returned as the result of the request: 506 Range = "Range" ":" ranges-specifier 508 A server MAY ignore the Range header. However, HTTP/1.1 origin 509 servers and intermediate caches ought to support byte ranges when 510 possible, since Range supports efficient recovery from partially 511 failed transfers, and supports efficient partial retrieval of large 512 entities. 514 If the server supports the Range header and the specified range or 515 ranges are appropriate for the entity: 517 o The presence of a Range header in an unconditional GET modifies 518 what is returned if the GET is otherwise successful. In other 519 words, the response carries a status code of 206 (Partial Content) 520 instead of 200 (OK). 522 o The presence of a Range header in a conditional GET (a request 523 using one or both of If-Modified-Since and If-None-Match, or one 524 or both of If-Unmodified-Since and If-Match) modifies what is 525 returned if the GET is otherwise successful and the condition is 526 true. It does not affect the 304 (Not Modified) response returned 527 if the conditional is false. 529 In some cases, it might be more appropriate to use the If-Range 530 header (see Section 5.3) in addition to the Range header. 532 If a proxy that supports ranges receives a Range request, forwards 533 the request to an inbound server, and receives an entire entity in 534 reply, it SHOULD only return the requested range to its client. It 535 SHOULD store the entire received response in its cache if that is 536 consistent with its cache allocation policies. 538 6. IANA Considerations 540 TBD. 542 7. Security Considerations 544 No additional security considerations have been identified beyond 545 those applicable to HTTP in general [Part1]. 547 8. Acknowledgments 549 Most of the specification of ranges is based on work originally done 550 by Ari Luotonen and John Franks, with additional input from Steve 551 Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin 552 Hamilton, Koen Holtman, Shel Kaplan, Paul Leach, Alex Lopez-Ortiz, 553 Larry Masinter, Jeff Mogul, Lou Montulli, David W. Morris, Luigi 554 Rizzo, and Bill Weihl. 556 9. References 558 9.1. Normative References 560 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 561 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 562 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, 563 and Message Parsing", draft-ietf-httpbis-p1-messaging-01 564 (work in progress), January 2008. 566 [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 567 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 568 and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload 569 and Content Negotiation", draft-ietf-httpbis-p3-payload-01 570 (work in progress), January 2008. 572 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 573 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 574 and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional 575 Requests", draft-ietf-httpbis-p4-conditional-01 (work in 576 progress), January 2008. 578 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 579 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 580 and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", 581 draft-ietf-httpbis-p6-cache-01 (work in progress), 582 January 2008. 584 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 585 Extensions (MIME) Part Two: Media Types", RFC 2046, 586 November 1996. 588 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 589 Requirement Levels", BCP 14, RFC 2119, March 1997. 591 9.2. Informative References 593 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 594 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 595 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 597 Appendix A. Internet Media Type multipart/byteranges 599 When an HTTP 206 (Partial Content) response message includes the 600 content of multiple ranges (a response to a request for multiple non- 601 overlapping ranges), these are transmitted as a multipart message- 602 body. The media type for this purpose is called "multipart/ 603 byteranges". 605 The multipart/byteranges media type includes two or more parts, each 606 with its own Content-Type and Content-Range fields. The required 607 boundary parameter specifies the boundary string used to separate 608 each body-part. 610 Media Type name: multipart 612 Media subtype name: byteranges 614 Required parameters: boundary 616 Optional parameters: none 618 Encoding considerations: only "7bit", "8bit", or "binary" are 619 permitted 621 Security considerations: none 622 For example: 624 HTTP/1.1 206 Partial Content 625 Date: Wed, 15 Nov 1995 06:25:24 GMT 626 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 627 Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES 629 --THIS_STRING_SEPARATES 630 Content-type: application/pdf 631 Content-range: bytes 500-999/8000 633 ...the first range... 634 --THIS_STRING_SEPARATES 635 Content-type: application/pdf 636 Content-range: bytes 7000-7999/8000 638 ...the second range 639 --THIS_STRING_SEPARATES-- 641 Notes: 643 1. Additional CRLFs may precede the first boundary string in the 644 entity. 646 2. Although [RFC2046] permits the boundary string to be quoted, some 647 existing implementations handle a quoted boundary string 648 incorrectly. 650 3. A number of browsers and servers were coded to an early draft of 651 the byteranges specification to use a media type of multipart/ 652 x-byteranges, which is almost, but not quite compatible with the 653 version documented in HTTP/1.1. 655 Appendix B. Compatibility with Previous Versions 657 B.1. Changes from RFC 2068 659 Transfer-coding and message lengths all interact in ways that 660 required fixing exactly when chunked encoding is used (to allow for 661 transfer encoding that may not be self delimiting); it was important 662 to straighten out exactly how message lengths are computed. 663 (Section 5.2, see also [Part1], [Part3] and [Part6]) 665 There are situations where a server (especially a proxy) does not 666 know the full length of a response but is capable of serving a 667 byterange request. We therefore need a mechanism to allow byteranges 668 with a content-range not indicating the full length of the message. 670 (Section 5.2) 672 Range request responses would become very verbose if all meta-data 673 were always returned; by allowing the server to only send needed 674 headers in a 206 response, this problem can be avoided. (Section 3.1 675 and 5.3) 677 Fix problem with unsatisfiable range requests; there are two cases: 678 syntactic problems, and range doesn't exist in the document. The 416 679 status code was needed to resolve this ambiguity needed to indicate 680 an error for a byte range request that falls outside of the actual 681 contents of a document. (Section 3.2, 5.2) 683 B.2. Changes from RFC 2616 685 Clarify that it is not ok to use a weak cache validator in a 206 686 response. (Section 3.1) 688 Appendix C. Change Log (to be removed by RFC Editor before publication) 690 C.1. Since RFC2616 692 Extracted relevant partitions from [RFC2616]. 694 C.2. Since draft-ietf-httpbis-p5-range-00 696 Closed issues: 698 o : "Cache 699 validators in 206 responses" 700 () 702 o : "Normative 703 and Informative references" 705 o : "Normative 706 up-to-date references" 708 Index 710 2 711 206 Partial Content (status code) 5 713 4 714 416 Requested Range Not Satisfiable (status code) 6 716 A 717 Accept-Ranges header 7 719 C 720 Content-Range header 7 722 G 723 Grammar 724 Accept-Ranges 7 725 acceptable-ranges 7 726 byte-content-range-spec 7 727 byte-range-resp-spec 7 728 byte-range-set 10 729 byte-range-spec 10 730 byte-ranges-specifier 10 731 bytes-unit 5 732 Content-Range 7 733 content-range-spec 7 734 first-byte-pos 10 735 If-Range 10 736 instance-length 7 737 last-byte-pos 10 738 other-range-unit 5 739 Range 12 740 range-unit 5 741 ranges-specifier 10 742 suffix-byte-range-spec 11 743 suffix-length 11 745 H 746 Headers 747 Accept-Ranges 7 748 Content-Range 7 749 If-Range 9 750 Range 10 752 I 753 If-Range header 9 755 M 756 Media Type 757 multipart/byteranges 14 758 multipart/x-byteranges 15 759 multipart/byteranges Media Type 14 760 multipart/x-byteranges Media Type 15 762 R 763 Range header 10 765 S 766 Status Codes 767 206 Partial Content 5 768 416 Requested Range Not Satisfiable 6 770 Authors' Addresses 772 Roy T. Fielding (editor) 773 Day Software 774 23 Corporate Plaza DR, Suite 280 775 Newport Beach, CA 92660 776 USA 778 Phone: +1-949-706-5300 779 Fax: +1-949-706-5305 780 Email: fielding@gbiv.com 781 URI: http://roy.gbiv.com/ 783 Jim Gettys 784 One Laptop per Child 785 21 Oak Knoll Road 786 Carlisle, MA 01741 787 USA 789 Email: jg@laptop.org 790 URI: http://www.laptop.org/ 792 Jeffrey C. Mogul 793 Hewlett-Packard Company 794 HP Labs, Large Scale Systems Group 795 1501 Page Mill Road, MS 1177 796 Palo Alto, CA 94304 797 USA 799 Email: JeffMogul@acm.org 801 Henrik Frystyk Nielsen 802 Microsoft Corporation 803 1 Microsoft Way 804 Redmond, WA 98052 805 USA 807 Email: henrikn@microsoft.com 808 Larry Masinter 809 Adobe Systems, Incorporated 810 345 Park Ave 811 San Jose, CA 95110 812 USA 814 Email: LMM@acm.org 815 URI: http://larry.masinter.net/ 817 Paul J. Leach 818 Microsoft Corporation 819 1 Microsoft Way 820 Redmond, WA 98052 822 Email: paulle@microsoft.com 824 Tim Berners-Lee 825 World Wide Web Consortium 826 MIT Computer Science and Artificial Intelligence Laboratory 827 The Stata Center, Building 32 828 32 Vassar Street 829 Cambridge, MA 02139 830 USA 832 Email: timbl@w3.org 833 URI: http://www.w3.org/People/Berners-Lee/ 835 Yves Lafon (editor) 836 World Wide Web Consortium 837 W3C / ERCIM 838 2004, rte des Lucioles 839 Sophia-Antipolis, AM 06902 840 France 842 Email: ylafon@w3.org 843 URI: http://www.raubacapeu.net/people/yves/ 844 Julian F. Reschke (editor) 845 greenbytes GmbH 846 Hafenweg 16 847 Muenster, NW 48155 848 Germany 850 Phone: +49 251 2807760 851 Fax: +49 251 2807761 852 Email: julian.reschke@greenbytes.de 853 URI: http://greenbytes.de/tech/webdav/ 855 Full Copyright Statement 857 Copyright (C) The IETF Trust (2008). 859 This document is subject to the rights, licenses and restrictions 860 contained in BCP 78, and except as set forth therein, the authors 861 retain all their rights. 863 This document and the information contained herein are provided on an 864 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 865 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 866 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 867 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 868 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 869 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 871 Intellectual Property 873 The IETF takes no position regarding the validity or scope of any 874 Intellectual Property Rights or other rights that might be claimed to 875 pertain to the implementation or use of the technology described in 876 this document or the extent to which any license under such rights 877 might or might not be available; nor does it represent that it has 878 made any independent effort to identify any such rights. Information 879 on the procedures with respect to rights in RFC documents can be 880 found in BCP 78 and BCP 79. 882 Copies of IPR disclosures made to the IETF Secretariat and any 883 assurances of licenses to be made available, or the result of an 884 attempt made to obtain a general license or permission for the use of 885 such proprietary rights by implementers or users of this 886 specification can be obtained from the IETF on-line IPR repository at 887 http://www.ietf.org/ipr. 889 The IETF invites any interested party to bring to its attention any 890 copyrights, patents or patent applications, or other proprietary 891 rights that may cover technology that may be required to implement 892 this standard. Please address the information to the IETF at 893 ietf-ipr@ietf.org. 895 Acknowledgment 897 Funding for the RFC Editor function is provided by the IETF 898 Administrative Support Activity (IASA).