1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | Internet Engineering Task Force (IETF) R. Fielding, Ed. |
8 | Request for Comments: 7233 Adobe |
9 | Obsoletes: 2616 Y. Lafon, Ed. |
10 | Category: Standards Track W3C |
11 | ISSN: 2070-1721 J. Reschke, Ed. |
12 | greenbytes |
13 | June 2014 |
14 | |
15 | |
16 | Hypertext Transfer Protocol (HTTP/1.1): Range Requests |
17 | |
18 | Abstract |
19 | |
20 | The Hypertext Transfer Protocol (HTTP) is a stateless application- |
21 | level protocol for distributed, collaborative, hypertext information |
22 | systems. This document defines range requests and the rules for |
23 | constructing and combining responses to those requests. |
24 | |
25 | Status of This Memo |
26 | |
27 | This is an Internet Standards Track document. |
28 | |
29 | This document is a product of the Internet Engineering Task Force |
30 | (IETF). It represents the consensus of the IETF community. It has |
31 | received public review and has been approved for publication by the |
32 | Internet Engineering Steering Group (IESG). Further information on |
33 | Internet Standards is available in Section 2 of RFC 5741. |
34 | |
35 | Information about the current status of this document, any errata, |
36 | and how to provide feedback on it may be obtained at |
37 | http://www.rfc-editor.org/info/rfc7233. |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
58 | Fielding, et al. Standards Track [Page 1] |
60 | RFC 7233 HTTP/1.1 Range Requests June 2014 |
61 | |
62 | |
63 | Copyright Notice |
64 | |
65 | Copyright (c) 2014 IETF Trust and the persons identified as the |
66 | document authors. All rights reserved. |
67 | |
68 | This document is subject to BCP 78 and the IETF Trust's Legal |
69 | Provisions Relating to IETF Documents |
70 | (http://trustee.ietf.org/license-info) in effect on the date of |
71 | publication of this document. Please review these documents |
72 | carefully, as they describe your rights and restrictions with respect |
73 | to this document. Code Components extracted from this document must |
74 | include Simplified BSD License text as described in Section 4.e of |
75 | the Trust Legal Provisions and are provided without warranty as |
76 | described in the Simplified BSD License. |
77 | |
78 | This document may contain material from IETF Documents or IETF |
79 | Contributions published or made publicly available before November |
80 | 10, 2008. The person(s) controlling the copyright in some of this |
81 | material may not have granted the IETF Trust the right to allow |
82 | modifications of such material outside the IETF Standards Process. |
83 | Without obtaining an adequate license from the person(s) controlling |
84 | the copyright in such materials, this document may not be modified |
85 | outside the IETF Standards Process, and derivative works of it may |
86 | not be created outside the IETF Standards Process, except to format |
87 | it for publication as an RFC or to translate it into languages other |
88 | than English. |
89 | |
90 | |
91 | |
92 | |
93 | |
94 | |
95 | |
96 | |
97 | |
98 | |
99 | |
100 | |
101 | |
102 | |
103 | |
104 | |
105 | |
106 | |
107 | |
108 | |
109 | |
110 | |
111 | |
112 | |
113 | |
114 | Fielding, et al. Standards Track [Page 2] |
116 | RFC 7233 HTTP/1.1 Range Requests June 2014 |
117 | |
118 | |
119 | Table of Contents |
120 | |
121 | 1. Introduction ....................................................4 |
122 | 1.1. Conformance and Error Handling .............................4 |
123 | 1.2. Syntax Notation ............................................4 |
124 | 2. Range Units .....................................................5 |
125 | 2.1. Byte Ranges ................................................5 |
126 | 2.2. Other Range Units ..........................................7 |
127 | 2.3. Accept-Ranges ..............................................7 |
128 | 3. Range Requests ..................................................8 |
129 | 3.1. Range ......................................................8 |
130 | 3.2. If-Range ...................................................9 |
131 | 4. Responses to a Range Request ...................................10 |
132 | 4.1. 206 Partial Content .......................................10 |
133 | 4.2. Content-Range .............................................12 |
134 | 4.3. Combining Ranges ..........................................14 |
135 | 4.4. 416 Range Not Satisfiable .................................15 |
136 | 5. IANA Considerations ............................................16 |
137 | 5.1. Range Unit Registry .......................................16 |
138 | 5.1.1. Procedure ..........................................16 |
139 | 5.1.2. Registrations ......................................16 |
140 | 5.2. Status Code Registration ..................................17 |
141 | 5.3. Header Field Registration .................................17 |
142 | 5.4. Internet Media Type Registration ..........................17 |
143 | 5.4.1. Internet Media Type multipart/byteranges ...........18 |
144 | 6. Security Considerations ........................................19 |
145 | 6.1. Denial-of-Service Attacks Using Range .....................19 |
146 | 7. Acknowledgments ................................................19 |
147 | 8. References .....................................................20 |
148 | 8.1. Normative References ......................................20 |
149 | 8.2. Informative References ....................................20 |
150 | Appendix A. Internet Media Type multipart/byteranges ..............21 |
151 | Appendix B. Changes from RFC 2616 .................................22 |
152 | Appendix C. Imported ABNF .........................................22 |
153 | Appendix D. Collected ABNF ........................................23 |
154 | Index .............................................................24 |
155 | |
156 | |
157 | |
158 | |
159 | |
160 | |
161 | |
162 | |
163 | |
164 | |
165 | |
166 | |
167 | |
168 | |
169 | |
170 | Fielding, et al. Standards Track [Page 3] |
172 | RFC 7233 HTTP/1.1 Range Requests June 2014 |
173 | |
174 | |
175 | 1. Introduction |
176 | |
177 | Hypertext Transfer Protocol (HTTP) clients often encounter |
178 | interrupted data transfers as a result of canceled requests or |
179 | dropped connections. When a client has stored a partial |
180 | representation, it is desirable to request the remainder of that |
181 | representation in a subsequent request rather than transfer the |
182 | entire representation. Likewise, devices with limited local storage |
183 | might benefit from being able to request only a subset of a larger |
184 | representation, such as a single page of a very large document, or |
185 | the dimensions of an embedded image. |
186 | |
187 | This document defines HTTP/1.1 range requests, partial responses, and |
188 | the multipart/byteranges media type. Range requests are an OPTIONAL |
189 | feature of HTTP, designed so that recipients not implementing this |
190 | feature (or not supporting it for the target resource) can respond as |
191 | if it is a normal GET request without impacting interoperability. |
192 | Partial responses are indicated by a distinct status code to not be |
193 | mistaken for full responses by caches that might not implement the |
194 | feature. |
195 | |
196 | Although the range request mechanism is designed to allow for |
197 | extensible range types, this specification only defines requests for |
198 | byte ranges. |
199 | |
200 | 1.1. Conformance and Error Handling |
201 | |
202 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
203 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
204 | document are to be interpreted as described in [RFC2119]. |
205 | |
206 | Conformance criteria and considerations regarding error handling are |
207 | defined in Section 2.5 of [RFC7230]. |
208 | |
209 | 1.2. Syntax Notation |
210 | |
211 | This specification uses the Augmented Backus-Naur Form (ABNF) |
212 | notation of [RFC5234] with a list extension, defined in Section 7 of |
213 | [RFC7230], that allows for compact definition of comma-separated |
214 | lists using a '#' operator (similar to how the '*' operator indicates |
215 | repetition). Appendix C describes rules imported from other |
216 | documents. Appendix D shows the collected grammar with all list |
217 | operators expanded to standard ABNF notation. |
218 | |
219 | |
220 | |
221 | |
222 | |
223 | |
224 | |
225 | |
226 | Fielding, et al. Standards Track [Page 4] |
228 | RFC 7233 HTTP/1.1 Range Requests June 2014 |
229 | |
230 | |
231 | 2. Range Units |
232 | |
233 | A representation can be partitioned into subranges according to |
234 | various structural units, depending on the structure inherent in the |
235 | representation's media type. This "range unit" is used in the |
236 | Accept-Ranges (Section 2.3) response header field to advertise |
237 | support for range requests, the Range (Section 3.1) request header |
238 | field to delineate the parts of a representation that are requested, |
239 | and the Content-Range (Section 4.2) payload header field to describe |
240 | which part of a representation is being transferred. |
241 | |
242 | range-unit = bytes-unit / other-range-unit |
243 | |
244 | 2.1. Byte Ranges |
245 | |
246 | Since representation data is transferred in payloads as a sequence of |
247 | octets, a byte range is a meaningful substructure for any |
248 | representation transferable over HTTP (Section 3 of [RFC7231]). The |
249 | "bytes" range unit is defined for expressing subranges of the data's |
250 | octet sequence. |
251 | |
252 | bytes-unit = "bytes" |
253 | |
254 | A byte-range request can specify a single range of bytes or a set of |
255 | ranges within a single representation. |
256 | |
257 | byte-ranges-specifier = bytes-unit "=" byte-range-set |
258 | byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec ) |
259 | byte-range-spec = first-byte-pos "-" [ last-byte-pos ] |
260 | first-byte-pos = 1*DIGIT |
261 | last-byte-pos = 1*DIGIT |
262 | |
263 | The first-byte-pos value in a byte-range-spec gives the byte-offset |
264 | of the first byte in a range. The last-byte-pos value gives the |
265 | byte-offset of the last byte in the range; that is, the byte |
266 | positions specified are inclusive. Byte offsets start at zero. |
267 | |
268 | Examples of byte-ranges-specifier values: |
269 | |
270 | o The first 500 bytes (byte offsets 0-499, inclusive): |
271 | |
272 | bytes=0-499 |
273 | |
274 | o The second 500 bytes (byte offsets 500-999, inclusive): |
275 | |
276 | bytes=500-999 |
277 | |
278 | |
279 | |
280 | |
281 | |
282 | Fielding, et al. Standards Track [Page 5] |
284 | RFC 7233 HTTP/1.1 Range Requests June 2014 |
285 | |
286 | |
287 | A byte-range-spec is invalid if the last-byte-pos value is present |
288 | and less than the first-byte-pos. |
289 | |
290 | A client can limit the number of bytes requested without knowing the |
291 | size of the selected representation. If the last-byte-pos value is |
292 | absent, or if the value is greater than or equal to the current |
293 | length of the representation data, the byte range is interpreted as |
294 | the remainder of the representation (i.e., the server replaces the |
295 | value of last-byte-pos with a value that is one less than the current |
296 | length of the selected representation). |
297 | |
298 | A client can request the last N bytes of the selected representation |
299 | using a suffix-byte-range-spec. |
300 | |
301 | suffix-byte-range-spec = "-" suffix-length |
302 | suffix-length = 1*DIGIT |
303 | |
304 | If the selected representation is shorter than the specified |
305 | suffix-length, the entire representation is used. |
306 | |
307 | Additional examples, assuming a representation of length 10000: |
308 | |
309 | o The final 500 bytes (byte offsets 9500-9999, inclusive): |
310 | |
311 | bytes=-500 |
312 | |
313 | Or: |
314 | |
315 | bytes=9500- |
316 | |
317 | o The first and last bytes only (bytes 0 and 9999): |
318 | |
319 | bytes=0-0,-1 |
320 | |
321 | o Other valid (but not canonical) specifications of the second 500 |
322 | bytes (byte offsets 500-999, inclusive): |
323 | |
324 | bytes=500-600,601-999 |
325 | bytes=500-700,601-999 |
326 | |
327 | If a valid byte-range-set includes at least one byte-range-spec with |
328 | a first-byte-pos that is less than the current length of the |
329 | representation, or at least one suffix-byte-range-spec with a |
330 | non-zero suffix-length, then the byte-range-set is satisfiable. |
331 | Otherwise, the byte-range-set is unsatisfiable. |
332 | |
333 | |
334 | |
335 | |
336 | |
337 | |
338 | Fielding, et al. Standards Track [Page 6] |
340 | RFC 7233 HTTP/1.1 Range Requests June 2014 |
341 | |
342 | |
343 | In the byte-range syntax, first-byte-pos, last-byte-pos, and |
344 | suffix-length are expressed as decimal number of octets. Since there |
345 | is no predefined limit to the length of a payload, recipients MUST |
346 | anticipate potentially large decimal numerals and prevent parsing |
347 | errors due to integer conversion overflows. |
348 | |
349 | 2.2. Other Range Units |
350 | |
351 | Range units are intended to be extensible. New range units ought to |
352 | be registered with IANA, as defined in Section 5.1. |
353 | |
354 | other-range-unit = token |
355 | |
356 | 2.3. Accept-Ranges |
357 | |
358 | The "Accept-Ranges" header field allows a server to indicate that it |
359 | supports range requests for the target resource. |
360 | |
361 | Accept-Ranges = acceptable-ranges |
362 | acceptable-ranges = 1#range-unit / "none" |
363 | |
364 | An origin server that supports byte-range requests for a given target |
365 | resource MAY send |
366 | |
367 | Accept-Ranges: bytes |
368 | |
369 | to indicate what range units are supported. A client MAY generate |
370 | range requests without having received this header field for the |
371 | resource involved. Range units are defined in Section 2. |
372 | |
373 | A server that does not support any kind of range request for the |
374 | target resource MAY send |
375 | |
376 | Accept-Ranges: none |
377 | |
378 | to advise the client not to attempt a range request. |
379 | |
380 | |
381 | |
382 | |
383 | |
384 | |
385 | |
386 | |
387 | |
388 | |
389 | |
390 | |
391 | |
392 | |
393 | |
394 | Fielding, et al. Standards Track [Page 7] |
396 | RFC 7233 HTTP/1.1 Range Requests June 2014 |
397 | |
398 | |
399 | 3. Range Requests |
400 | |
401 | 3.1. Range |
402 | |
403 | The "Range" header field on a GET request modifies the method |
404 | semantics to request transfer of only one or more subranges of the |
405 | selected representation data, rather than the entire selected |
406 | representation data. |
407 | |
408 | Range = byte-ranges-specifier / other-ranges-specifier |
409 | other-ranges-specifier = other-range-unit "=" other-range-set |
410 | other-range-set = 1*VCHAR |
411 | |
412 | A server MAY ignore the Range header field. However, origin servers |
413 | and intermediate caches ought to support byte ranges when possible, |
414 | since Range supports efficient recovery from partially failed |
415 | transfers and partial retrieval of large representations. A server |
416 | MUST ignore a Range header field received with a request method other |
417 | than GET. |
418 | |
419 | An origin server MUST ignore a Range header field that contains a |
420 | range unit it does not understand. A proxy MAY discard a Range |
421 | header field that contains a range unit it does not understand. |
422 | |
423 | A server that supports range requests MAY ignore or reject a Range |
424 | header field that consists of more than two overlapping ranges, or a |
425 | set of many small ranges that are not listed in ascending order, |
426 | since both are indications of either a broken client or a deliberate |
427 | denial-of-service attack (Section 6.1). A client SHOULD NOT request |
428 | multiple ranges that are inherently less efficient to process and |
429 | transfer than a single range that encompasses the same data. |
430 | |
431 | A client that is requesting multiple ranges SHOULD list those ranges |
432 | in ascending order (the order in which they would typically be |
433 | received in a complete representation) unless there is a specific |
434 | need to request a later part earlier. For example, a user agent |
435 | processing a large representation with an internal catalog of parts |
436 | might need to request later parts first, particularly if the |
437 | representation consists of pages stored in reverse order and the user |
438 | agent wishes to transfer one page at a time. |
439 | |
440 | The Range header field is evaluated after evaluating the precondition |
441 | header fields defined in [RFC7232], and only if the result in absence |
442 | of the Range header field would be a 200 (OK) response. In other |
443 | words, Range is ignored when a conditional GET would result in a 304 |
444 | (Not Modified) response. |
445 | |
446 | |
447 | |
448 | |
449 | |
450 | Fielding, et al. Standards Track [Page 8] |
452 | RFC 7233 HTTP/1.1 Range Requests June 2014 |
453 | |
454 | |
455 | The If-Range header field (Section 3.2) can be used as a precondition |
.../cache/cache_range.c 150 |
456 | to applying the Range header field. |
.../cache/cache_range.c 193 |
| |
.../cache/cache_range.c 209 |
457 | |
458 | If all of the preconditions are true, the server supports the Range |
459 | header field for the target resource, and the specified range(s) are |
460 | valid and satisfiable (as defined in Section 2.1), the server SHOULD |
461 | send a 206 (Partial Content) response with a payload containing one |
462 | or more partial representations that correspond to the satisfiable |
463 | ranges requested, as defined in Section 4. |
464 | |
465 | If all of the preconditions are true, the server supports the Range |
466 | header field for the target resource, and the specified range(s) are |
467 | invalid or unsatisfiable, the server SHOULD send a 416 (Range Not |
468 | Satisfiable) response. |
469 | |
470 | 3.2. If-Range |
471 | |
472 | If a client has a partial copy of a representation and wishes to have |
473 | an up-to-date copy of the entire representation, it could use the |
474 | Range header field with a conditional GET (using either or both of |
475 | If-Unmodified-Since and If-Match.) However, if the precondition |
476 | fails because the representation has been modified, the client would |
477 | then have to make a second request to obtain the entire current |
478 | representation. |
479 | |
480 | The "If-Range" header field allows a client to "short-circuit" the |
481 | second request. Informally, its meaning is as follows: if the |
482 | representation is unchanged, send me the part(s) that I am requesting |
483 | in Range; otherwise, send me the entire representation. |
484 | |
485 | If-Range = entity-tag / HTTP-date |
486 | |
487 | A client MUST NOT generate an If-Range header field in a request that |
488 | does not contain a Range header field. A server MUST ignore an |
489 | If-Range header field received in a request that does not contain a |
490 | Range header field. An origin server MUST ignore an If-Range header |
491 | field received in a request for a target resource that does not |
492 | support Range requests. |
493 | |
494 | A client MUST NOT generate an If-Range header field containing an |
495 | entity-tag that is marked as weak. A client MUST NOT generate an |
496 | If-Range header field containing an HTTP-date unless the client has |
497 | no entity-tag for the corresponding representation and the date is a |
498 | strong validator in the sense defined by Section 2.2.2 of [RFC7232]. |
499 | |
500 | A server that evaluates an If-Range precondition MUST use the strong |
.../cache/cache_range.c 154 |
501 | comparison function when comparing entity-tags (Section 2.3.2 of |
502 | [RFC7232]) and MUST evaluate the condition as false if an HTTP-date |
.../cache/cache_range.c 169 |
503 | |
504 | |
505 | |
506 | Fielding, et al. Standards Track [Page 9] |
508 | RFC 7233 HTTP/1.1 Range Requests June 2014 |
509 | |
510 | |
511 | validator is provided that is not a strong validator in the sense |
512 | defined by Section 2.2.2 of [RFC7232]. A valid entity-tag can be |
513 | distinguished from a valid HTTP-date by examining the first two |
.../cache/cache_range.c 158 |
514 | characters for a DQUOTE. |
515 | |
516 | If the validator given in the If-Range header field matches the |
517 | current validator for the selected representation of the target |
518 | resource, then the server SHOULD process the Range header field as |
519 | requested. If the validator does not match, the server MUST ignore |
520 | the Range header field. Note that this comparison by exact match, |
521 | including when the validator is an HTTP-date, differs from the |
522 | "earlier than or equal to" comparison used when evaluating an |
523 | If-Unmodified-Since conditional. |
524 | |
525 | 4. Responses to a Range Request |
526 | |
527 | 4.1. 206 Partial Content |
528 | |
529 | The 206 (Partial Content) status code indicates that the server is |
530 | successfully fulfilling a range request for the target resource by |
531 | transferring one or more parts of the selected representation that |
532 | correspond to the satisfiable ranges found in the request's Range |
533 | header field (Section 3.1). |
534 | |
535 | If a single part is being transferred, the server generating the 206 |
536 | response MUST generate a Content-Range header field, describing what |
537 | range of the selected representation is enclosed, and a payload |
538 | consisting of the range. For example: |
539 | |
540 | HTTP/1.1 206 Partial Content |
541 | Date: Wed, 15 Nov 1995 06:25:24 GMT |
542 | Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT |
543 | Content-Range: bytes 21010-47021/47022 |
544 | Content-Length: 26012 |
545 | Content-Type: image/gif |
546 | |
547 | ... 26012 bytes of partial image data ... |
548 | |
549 | If multiple parts are being transferred, the server generating the |
550 | 206 response MUST generate a "multipart/byteranges" payload, as |
551 | defined in Appendix A, and a Content-Type header field containing the |
552 | multipart/byteranges media type and its required boundary parameter. |
553 | To avoid confusion with single-part responses, a server MUST NOT |
554 | generate a Content-Range header field in the HTTP header section of a |
555 | multiple part response (this field will be sent in each part |
556 | instead). |
557 | |
558 | |
559 | |
560 | |
561 | |
562 | Fielding, et al. Standards Track [Page 10] |
564 | RFC 7233 HTTP/1.1 Range Requests June 2014 |
565 | |
566 | |
567 | Within the header area of each body part in the multipart payload, |
568 | the server MUST generate a Content-Range header field corresponding |
569 | to the range being enclosed in that body part. If the selected |
570 | representation would have had a Content-Type header field in a 200 |
571 | (OK) response, the server SHOULD generate that same Content-Type |
572 | field in the header area of each body part. For example: |
573 | |
574 | HTTP/1.1 206 Partial Content |
575 | Date: Wed, 15 Nov 1995 06:25:24 GMT |
576 | Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT |
577 | Content-Length: 1741 |
578 | Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES |
579 | |
580 | --THIS_STRING_SEPARATES |
581 | Content-Type: application/pdf |
582 | Content-Range: bytes 500-999/8000 |
583 | |
584 | ...the first range... |
585 | --THIS_STRING_SEPARATES |
586 | Content-Type: application/pdf |
587 | Content-Range: bytes 7000-7999/8000 |
588 | |
589 | ...the second range |
590 | --THIS_STRING_SEPARATES-- |
591 | |
592 | When multiple ranges are requested, a server MAY coalesce any of the |
593 | ranges that overlap, or that are separated by a gap that is smaller |
594 | than the overhead of sending multiple parts, regardless of the order |
595 | in which the corresponding byte-range-spec appeared in the received |
596 | Range header field. Since the typical overhead between parts of a |
597 | multipart/byteranges payload is around 80 bytes, depending on the |
598 | selected representation's media type and the chosen boundary |
599 | parameter length, it can be less efficient to transfer many small |
600 | disjoint parts than it is to transfer the entire selected |
601 | representation. |
602 | |
603 | A server MUST NOT generate a multipart response to a request for a |
604 | single range, since a client that does not request multiple parts |
605 | might not support multipart responses. However, a server MAY |
606 | generate a multipart/byteranges payload with only a single body part |
607 | if multiple ranges were requested and only one range was found to be |
608 | satisfiable or only one range remained after coalescing. A client |
609 | that cannot process a multipart/byteranges response MUST NOT generate |
610 | a request that asks for multiple ranges. |
611 | |
612 | When a multipart response payload is generated, the server SHOULD |
613 | send the parts in the same order that the corresponding |
614 | byte-range-spec appeared in the received Range header field, |
615 | |
616 | |
617 | |
618 | Fielding, et al. Standards Track [Page 11] |
620 | RFC 7233 HTTP/1.1 Range Requests June 2014 |
621 | |
622 | |
623 | excluding those ranges that were deemed unsatisfiable or that were |
624 | coalesced into other ranges. A client that receives a multipart |
625 | response MUST inspect the Content-Range header field present in each |
626 | body part in order to determine which range is contained in that body |
627 | part; a client cannot rely on receiving the same ranges that it |
628 | requested, nor the same order that it requested. |
629 | |
630 | When a 206 response is generated, the server MUST generate the |
631 | following header fields, in addition to those required above, if the |
632 | field would have been sent in a 200 (OK) response to the same |
633 | request: Date, Cache-Control, ETag, Expires, Content-Location, and |
634 | Vary. |
635 | |
636 | If a 206 is generated in response to a request with an If-Range |
637 | header field, the sender SHOULD NOT generate other representation |
638 | header fields beyond those required above, because the client is |
639 | understood to already have a prior response containing those header |
640 | fields. Otherwise, the sender MUST generate all of the |
641 | representation header fields that would have been sent in a 200 (OK) |
642 | response to the same request. |
643 | |
644 | A 206 response is cacheable by default; i.e., unless otherwise |
645 | indicated by explicit cache controls (see Section 4.2.2 of |
646 | [RFC7234]). |
647 | |
648 | 4.2. Content-Range |
649 | |
650 | The "Content-Range" header field is sent in a single part 206 |
651 | (Partial Content) response to indicate the partial range of the |
652 | selected representation enclosed as the message payload, sent in each |
653 | part of a multipart 206 response to indicate the range enclosed |
654 | within each body part, and sent in 416 (Range Not Satisfiable) |
655 | responses to provide information about the selected representation. |
656 | |
657 | Content-Range = byte-content-range |
658 | / other-content-range |
659 | |
660 | byte-content-range = bytes-unit SP |
661 | ( byte-range-resp / unsatisfied-range ) |
662 | |
663 | byte-range-resp = byte-range "/" ( complete-length / "*" ) |
664 | byte-range = first-byte-pos "-" last-byte-pos |
665 | unsatisfied-range = "*/" complete-length |
666 | |
667 | complete-length = 1*DIGIT |
668 | |
669 | other-content-range = other-range-unit SP other-range-resp |
670 | other-range-resp = *CHAR |
671 | |
672 | |
673 | |
674 | Fielding, et al. Standards Track [Page 12] |
676 | RFC 7233 HTTP/1.1 Range Requests June 2014 |
677 | |
678 | |
679 | If a 206 (Partial Content) response contains a Content-Range header |
680 | field with a range unit (Section 2) that the recipient does not |
681 | understand, the recipient MUST NOT attempt to recombine it with a |
682 | stored representation. A proxy that receives such a message SHOULD |
683 | forward it downstream. |
684 | |
685 | For byte ranges, a sender SHOULD indicate the complete length of the |
686 | representation from which the range has been extracted, unless the |
687 | complete length is unknown or difficult to determine. An asterisk |
688 | character ("*") in place of the complete-length indicates that the |
689 | representation length was unknown when the header field was |
690 | generated. |
691 | |
692 | The following example illustrates when the complete length of the |
693 | selected representation is known by the sender to be 1234 bytes: |
694 | |
695 | Content-Range: bytes 42-1233/1234 |
696 | |
697 | and this second example illustrates when the complete length is |
698 | unknown: |
699 | |
700 | Content-Range: bytes 42-1233/* |
701 | |
702 | A Content-Range field value is invalid if it contains a |
703 | byte-range-resp that has a last-byte-pos value less than its |
704 | first-byte-pos value, or a complete-length value less than or equal |
705 | to its last-byte-pos value. The recipient of an invalid |
706 | Content-Range MUST NOT attempt to recombine the received content with |
707 | a stored representation. |
708 | |
709 | A server generating a 416 (Range Not Satisfiable) response to a |
710 | byte-range request SHOULD send a Content-Range header field with an |
711 | unsatisfied-range value, as in the following example: |
712 | |
713 | Content-Range: bytes */1234 |
714 | |
715 | The complete-length in a 416 response indicates the current length of |
716 | the selected representation. |
717 | |
718 | The Content-Range header field has no meaning for status codes that |
719 | do not explicitly describe its semantic. For this specification, |
720 | only the 206 (Partial Content) and 416 (Range Not Satisfiable) status |
721 | codes describe a meaning for Content-Range. |
722 | |
723 | |
724 | |
725 | |
726 | |
727 | |
728 | |
729 | |
730 | Fielding, et al. Standards Track [Page 13] |
732 | RFC 7233 HTTP/1.1 Range Requests June 2014 |
733 | |
734 | |
735 | The following are examples of Content-Range values in which the |
736 | selected representation contains a total of 1234 bytes: |
737 | |
738 | o The first 500 bytes: |
739 | |
740 | Content-Range: bytes 0-499/1234 |
741 | |
742 | o The second 500 bytes: |
743 | |
744 | Content-Range: bytes 500-999/1234 |
745 | |
746 | o All except for the first 500 bytes: |
747 | |
748 | Content-Range: bytes 500-1233/1234 |
749 | |
750 | o The last 500 bytes: |
751 | |
752 | Content-Range: bytes 734-1233/1234 |
753 | |
754 | 4.3. Combining Ranges |
755 | |
756 | A response might transfer only a subrange of a representation if the |
757 | connection closed prematurely or if the request used one or more |
758 | Range specifications. After several such transfers, a client might |
759 | have received several ranges of the same representation. These |
760 | ranges can only be safely combined if they all have in common the |
761 | same strong validator (Section 2.1 of [RFC7232]). |
762 | |
763 | A client that has received multiple partial responses to GET requests |
764 | on a target resource MAY combine those responses into a larger |
765 | continuous range if they share the same strong validator. |
766 | |
767 | If the most recent response is an incomplete 200 (OK) response, then |
768 | the header fields of that response are used for any combined response |
769 | and replace those of the matching stored responses. |
770 | |
771 | If the most recent response is a 206 (Partial Content) response and |
772 | at least one of the matching stored responses is a 200 (OK), then the |
773 | combined response header fields consist of the most recent 200 |
774 | response's header fields. If all of the matching stored responses |
775 | are 206 responses, then the stored response with the most recent |
776 | header fields is used as the source of header fields for the combined |
777 | response, except that the client MUST use other header fields |
778 | provided in the new response, aside from Content-Range, to replace |
779 | all instances of the corresponding header fields in the stored |
780 | response. |
781 | |
782 | |
783 | |
784 | |
785 | |
786 | Fielding, et al. Standards Track [Page 14] |
788 | RFC 7233 HTTP/1.1 Range Requests June 2014 |
789 | |
790 | |
791 | The combined response message body consists of the union of partial |
792 | content ranges in the new response and each of the selected |
793 | responses. If the union consists of the entire range of the |
794 | representation, then the client MUST process the combined response as |
795 | if it were a complete 200 (OK) response, including a Content-Length |
796 | header field that reflects the complete length. Otherwise, the |
797 | client MUST process the set of continuous ranges as one of the |
798 | following: an incomplete 200 (OK) response if the combined response |
799 | is a prefix of the representation, a single 206 (Partial Content) |
800 | response containing a multipart/byteranges body, or multiple 206 |
801 | (Partial Content) responses, each with one continuous range that is |
802 | indicated by a Content-Range header field. |
803 | |
804 | 4.4. 416 Range Not Satisfiable |
805 | |
806 | The 416 (Range Not Satisfiable) status code indicates that none of |
807 | the ranges in the request's Range header field (Section 3.1) overlap |
808 | the current extent of the selected resource or that the set of ranges |
809 | requested has been rejected due to invalid ranges or an excessive |
810 | request of small or overlapping ranges. |
811 | |
812 | For byte ranges, failing to overlap the current extent means that the |
813 | first-byte-pos of all of the byte-range-spec values were greater than |
814 | the current length of the selected representation. When this status |
815 | code is generated in response to a byte-range request, the sender |
816 | SHOULD generate a Content-Range header field specifying the current |
817 | length of the selected representation (Section 4.2). |
818 | |
819 | For example: |
820 | |
821 | HTTP/1.1 416 Range Not Satisfiable |
822 | Date: Fri, 20 Jan 2012 15:41:54 GMT |
823 | Content-Range: bytes */47022 |
824 | |
825 | Note: Because servers are free to ignore Range, many |
826 | implementations will simply respond with the entire selected |
827 | representation in a 200 (OK) response. That is partly because |
828 | most clients are prepared to receive a 200 (OK) to complete the |
829 | task (albeit less efficiently) and partly because clients might |
830 | not stop making an invalid partial request until they have |
831 | received a complete representation. Thus, clients cannot depend |
832 | on receiving a 416 (Range Not Satisfiable) response even when it |
833 | is most appropriate. |
834 | |
835 | |
836 | |
837 | |
838 | |
839 | |
840 | |
841 | |
842 | Fielding, et al. Standards Track [Page 15] |
844 | RFC 7233 HTTP/1.1 Range Requests June 2014 |
845 | |
846 | |
847 | 5. IANA Considerations |
848 | |
849 | 5.1. Range Unit Registry |
850 | |
851 | The "HTTP Range Unit Registry" defines the namespace for the range |
852 | unit names and refers to their corresponding specifications. The |
853 | registry has been created and is now maintained at |
854 | <http://www.iana.org/assignments/http-parameters>. |
855 | |
856 | 5.1.1. Procedure |
857 | |
858 | Registration of an HTTP Range Unit MUST include the following fields: |
859 | |
860 | o Name |
861 | |
862 | o Description |
863 | |
864 | o Pointer to specification text |
865 | |
866 | Values to be added to this namespace require IETF Review (see |
867 | [RFC5226], Section 4.1). |
868 | |
869 | 5.1.2. Registrations |
870 | |
871 | The initial range unit registry contains the registrations below: |
872 | |
873 | +-------------+---------------------------------------+-------------+ |
874 | | Range Unit | Description | Reference | |
875 | | Name | | | |
876 | +-------------+---------------------------------------+-------------+ |
877 | | bytes | a range of octets | Section 2.1 | |
878 | | none | reserved as keyword, indicating no | Section 2.3 | |
879 | | | ranges are supported | | |
880 | +-------------+---------------------------------------+-------------+ |
881 | |
882 | The change controller is: "IETF (iesg@ietf.org) - Internet |
883 | Engineering Task Force". |
884 | |
885 | |
886 | |
887 | |
888 | |
889 | |
890 | |
891 | |
892 | |
893 | |
894 | |
895 | |
896 | |
897 | |
898 | Fielding, et al. Standards Track [Page 16] |
900 | RFC 7233 HTTP/1.1 Range Requests June 2014 |
901 | |
902 | |
903 | 5.2. Status Code Registration |
904 | |
905 | The "Hypertext Transfer Protocol (HTTP) Status Code Registry" located |
906 | at <http://www.iana.org/assignments/http-status-codes> has been |
907 | updated to include the registrations below: |
908 | |
909 | +-------+-----------------------+-------------+ |
910 | | Value | Description | Reference | |
911 | +-------+-----------------------+-------------+ |
912 | | 206 | Partial Content | Section 4.1 | |
913 | | 416 | Range Not Satisfiable | Section 4.4 | |
914 | +-------+-----------------------+-------------+ |
915 | |
916 | 5.3. Header Field Registration |
917 | |
918 | HTTP header fields are registered within the "Message Headers" |
919 | registry maintained at |
920 | <http://www.iana.org/assignments/message-headers/>. |
921 | |
922 | This document defines the following HTTP header fields, so their |
923 | associated registry entries have been updated according to the |
924 | permanent registrations below (see [BCP90]): |
925 | |
926 | +-------------------+----------+----------+-------------+ |
927 | | Header Field Name | Protocol | Status | Reference | |
928 | +-------------------+----------+----------+-------------+ |
929 | | Accept-Ranges | http | standard | Section 2.3 | |
930 | | Content-Range | http | standard | Section 4.2 | |
931 | | If-Range | http | standard | Section 3.2 | |
932 | | Range | http | standard | Section 3.1 | |
933 | +-------------------+----------+----------+-------------+ |
934 | |
935 | The change controller is: "IETF (iesg@ietf.org) - Internet |
936 | Engineering Task Force". |
937 | |
938 | 5.4. Internet Media Type Registration |
939 | |
940 | IANA maintains the registry of Internet media types [BCP13] at |
941 | <http://www.iana.org/assignments/media-types>. |
942 | |
943 | This document serves as the specification for the Internet media type |
944 | "multipart/byteranges". The following has been registered with IANA. |
945 | |
946 | |
947 | |
948 | |
949 | |
950 | |
951 | |
952 | |
953 | |
954 | Fielding, et al. Standards Track [Page 17] |
956 | RFC 7233 HTTP/1.1 Range Requests June 2014 |
957 | |
958 | |
959 | 5.4.1. Internet Media Type multipart/byteranges |
960 | |
961 | Type name: multipart |
962 | |
963 | Subtype name: byteranges |
964 | |
965 | Required parameters: boundary |
966 | |
967 | Optional parameters: N/A |
968 | |
969 | Encoding considerations: only "7bit", "8bit", or "binary" are |
970 | permitted |
971 | |
972 | Security considerations: see Section 6 |
973 | |
974 | Interoperability considerations: N/A |
975 | |
976 | Published specification: This specification (see Appendix A). |
977 | |
978 | Applications that use this media type: HTTP components supporting |
979 | multiple ranges in a single request. |
980 | |
981 | Fragment identifier considerations: N/A |
982 | |
983 | Additional information: |
984 | |
985 | Deprecated alias names for this type: N/A |
986 | |
987 | Magic number(s): N/A |
988 | |
989 | File extension(s): N/A |
990 | |
991 | Macintosh file type code(s): N/A |
992 | |
993 | Person and email address to contact for further information: See |
994 | Authors' Addresses section. |
995 | |
996 | Intended usage: COMMON |
997 | |
998 | Restrictions on usage: N/A |
999 | |
1000 | Author: See Authors' Addresses section. |
1001 | |
1002 | Change controller: IESG |
1003 | |
1004 | |
1005 | |
1006 | |
1007 | |
1008 | |
1009 | |
1010 | Fielding, et al. Standards Track [Page 18] |
1012 | RFC 7233 HTTP/1.1 Range Requests June 2014 |
1013 | |
1014 | |
1015 | 6. Security Considerations |
1016 | |
1017 | This section is meant to inform developers, information providers, |
1018 | and users of known security concerns specific to the HTTP range |
1019 | request mechanisms. More general security considerations are |
1020 | addressed in HTTP messaging [RFC7230] and semantics [RFC7231]. |
1021 | |
1022 | 6.1. Denial-of-Service Attacks Using Range |
1023 | |
1024 | Unconstrained multiple range requests are susceptible to denial-of- |
1025 | service attacks because the effort required to request many |
1026 | overlapping ranges of the same data is tiny compared to the time, |
1027 | memory, and bandwidth consumed by attempting to serve the requested |
1028 | data in many parts. Servers ought to ignore, coalesce, or reject |
1029 | egregious range requests, such as requests for more than two |
1030 | overlapping ranges or for many small ranges in a single set, |
1031 | particularly when the ranges are requested out of order for no |
1032 | apparent reason. Multipart range requests are not designed to |
1033 | support random access. |
1034 | |
1035 | 7. Acknowledgments |
1036 | |
1037 | See Section 10 of [RFC7230]. |
1038 | |
1039 | |
1040 | |
1041 | |
1042 | |
1043 | |
1044 | |
1045 | |
1046 | |
1047 | |
1048 | |
1049 | |
1050 | |
1051 | |
1052 | |
1053 | |
1054 | |
1055 | |
1056 | |
1057 | |
1058 | |
1059 | |
1060 | |
1061 | |
1062 | |
1063 | |
1064 | |
1065 | |
1066 | Fielding, et al. Standards Track [Page 19] |
1068 | RFC 7233 HTTP/1.1 Range Requests June 2014 |
1069 | |
1070 | |
1071 | 8. References |
1072 | |
1073 | 8.1. Normative References |
1074 | |
1075 | [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail |
1076 | Extensions (MIME) Part Two: Media Types", RFC 2046, |
1077 | November 1996. |
1078 | |
1079 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
1080 | Requirement Levels", BCP 14, RFC 2119, March 1997. |
1081 | |
1082 | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax |
1083 | Specifications: ABNF", STD 68, RFC 5234, January 2008. |
1084 | |
1085 | [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
1086 | Protocol (HTTP/1.1): Message Syntax and Routing", |
1087 | RFC 7230, June 2014. |
1088 | |
1089 | [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
1090 | Protocol (HTTP/1.1): Semantics and Content", RFC 7231, |
1091 | June 2014. |
1092 | |
1093 | [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
1094 | Protocol (HTTP/1.1): Conditional Requests", RFC 7232, |
1095 | June 2014. |
1096 | |
1097 | [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, |
1098 | Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", |
1099 | RFC 7234, June 2014. |
1100 | |
1101 | 8.2. Informative References |
1102 | |
1103 | [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type |
1104 | Specifications and Registration Procedures", BCP 13, |
1105 | RFC 6838, January 2013. |
1106 | |
1107 | [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration |
1108 | Procedures for Message Header Fields", BCP 90, RFC 3864, |
1109 | September 2004. |
1110 | |
1111 | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |
1112 | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |
1113 | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |
1114 | |
1115 | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an |
1116 | IANA Considerations Section in RFCs", BCP 26, RFC 5226, |
1117 | May 2008. |
1118 | |
1119 | |
1120 | |
1121 | |
1122 | Fielding, et al. Standards Track [Page 20] |
1124 | RFC 7233 HTTP/1.1 Range Requests June 2014 |
1125 | |
1126 | |
1127 | Appendix A. Internet Media Type multipart/byteranges |
1128 | |
1129 | When a 206 (Partial Content) response message includes the content of |
1130 | multiple ranges, they are transmitted as body parts in a multipart |
1131 | message body ([RFC2046], Section 5.1) with the media type of |
1132 | "multipart/byteranges". |
1133 | |
1134 | The multipart/byteranges media type includes one or more body parts, |
1135 | each with its own Content-Type and Content-Range fields. The |
1136 | required boundary parameter specifies the boundary string used to |
1137 | separate each body part. |
1138 | |
1139 | Implementation Notes: |
1140 | |
1141 | 1. Additional CRLFs might precede the first boundary string in the |
1142 | body. |
1143 | |
1144 | 2. Although [RFC2046] permits the boundary string to be quoted, some |
1145 | existing implementations handle a quoted boundary string |
1146 | incorrectly. |
1147 | |
1148 | 3. A number of clients and servers were coded to an early draft of |
1149 | the byteranges specification that used a media type of multipart/ |
1150 | x-byteranges, which is almost (but not quite) compatible with |
1151 | this type. |
1152 | |
1153 | Despite the name, the "multipart/byteranges" media type is not |
1154 | limited to byte ranges. The following example uses an "exampleunit" |
1155 | range unit: |
1156 | |
1157 | HTTP/1.1 206 Partial Content |
1158 | Date: Tue, 14 Nov 1995 06:25:24 GMT |
1159 | Last-Modified: Tue, 14 July 04:58:08 GMT |
1160 | Content-Length: 2331785 |
1161 | Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES |
1162 | |
1163 | --THIS_STRING_SEPARATES |
1164 | Content-Type: video/example |
1165 | Content-Range: exampleunit 1.2-4.3/25 |
1166 | |
1167 | ...the first range... |
1168 | --THIS_STRING_SEPARATES |
1169 | Content-Type: video/example |
1170 | Content-Range: exampleunit 11.2-14.3/25 |
1171 | |
1172 | ...the second range |
1173 | --THIS_STRING_SEPARATES-- |
1174 | |
1175 | |
1176 | |
1177 | |
1178 | Fielding, et al. Standards Track [Page 21] |
1180 | RFC 7233 HTTP/1.1 Range Requests June 2014 |
1181 | |
1182 | |
1183 | Appendix B. Changes from RFC 2616 |
1184 | |
1185 | Servers are given more leeway in how they respond to a range request, |
1186 | in order to mitigate abuse by malicious (or just greedy) clients. |
1187 | (Section 3.1) |
1188 | |
1189 | A weak validator cannot be used in a 206 response. (Section 4.1) |
1190 | |
1191 | The Content-Range header field only has meaning when the status code |
1192 | explicitly defines its use. (Section 4.2) |
1193 | |
1194 | This specification introduces a Range Unit Registry. (Section 5.1) |
1195 | |
1196 | multipart/byteranges can consist of a single part. (Appendix A) |
1197 | |
1198 | Appendix C. Imported ABNF |
1199 | |
1200 | The following core rules are included by reference, as defined in |
1201 | Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), |
1202 | CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double |
1203 | quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any |
1204 | 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII |
1205 | character). |
1206 | |
1207 | Note that all rules derived from token are to be compared |
.../cache/cache.h 683 |
1208 | case-insensitively, like range-unit and acceptable-ranges. |
.../cache/cache.h 710 |
1209 | |
1210 | The rules below are defined in [RFC7230]: |
1211 | |
1212 | OWS = <OWS, see [RFC7230], Section 3.2.3> |
1213 | token = <token, see [RFC7230], Section 3.2.6> |
1214 | |
1215 | The rules below are defined in other parts: |
1216 | |
1217 | HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1> |
1218 | entity-tag = <entity-tag, see [RFC7232], Section 2.3> |
1219 | |
1220 | |
1221 | |
1222 | |
1223 | |
1224 | |
1225 | |
1226 | |
1227 | |
1228 | |
1229 | |
1230 | |
1231 | |
1232 | |
1233 | |
1234 | Fielding, et al. Standards Track [Page 22] |
1236 | RFC 7233 HTTP/1.1 Range Requests June 2014 |
1237 | |
1238 | |
1239 | Appendix D. Collected ABNF |
1240 | |
1241 | In the collected ABNF below, list rules are expanded as per Section |
1242 | 1.2 of [RFC7230]. |
1243 | |
1244 | Accept-Ranges = acceptable-ranges |
1245 | |
1246 | Content-Range = byte-content-range / other-content-range |
1247 | |
1248 | HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1> |
1249 | |
1250 | If-Range = entity-tag / HTTP-date |
1251 | |
1252 | OWS = <OWS, see [RFC7230], Section 3.2.3> |
1253 | |
1254 | Range = byte-ranges-specifier / other-ranges-specifier |
1255 | |
1256 | acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS |
1257 | range-unit ] ) ) / "none" |
1258 | |
1259 | byte-content-range = bytes-unit SP ( byte-range-resp / |
1260 | unsatisfied-range ) |
1261 | byte-range = first-byte-pos "-" last-byte-pos |
1262 | byte-range-resp = byte-range "/" ( complete-length / "*" ) |
1263 | byte-range-set = *( "," OWS ) ( byte-range-spec / |
1264 | suffix-byte-range-spec ) *( OWS "," [ OWS ( byte-range-spec / |
1265 | suffix-byte-range-spec ) ] ) |
1266 | byte-range-spec = first-byte-pos "-" [ last-byte-pos ] |
1267 | byte-ranges-specifier = bytes-unit "=" byte-range-set |
1268 | bytes-unit = "bytes" |
1269 | |
1270 | complete-length = 1*DIGIT |
1271 | |
1272 | entity-tag = <entity-tag, see [RFC7232], Section 2.3> |
1273 | |
1274 | first-byte-pos = 1*DIGIT |
1275 | |
1276 | last-byte-pos = 1*DIGIT |
1277 | |
1278 | other-content-range = other-range-unit SP other-range-resp |
1279 | other-range-resp = *CHAR |
1280 | other-range-set = 1*VCHAR |
1281 | other-range-unit = token |
1282 | other-ranges-specifier = other-range-unit "=" other-range-set |
1283 | |
1284 | range-unit = bytes-unit / other-range-unit |
1285 | |
1286 | suffix-byte-range-spec = "-" suffix-length |
1287 | |
1288 | |
1289 | |
1290 | Fielding, et al. Standards Track [Page 23] |
1348 | RFC 7233 HTTP/1.1 Range Requests June 2014 |
1349 | |
1350 | |
1351 | I |
1352 | If-Range header field 9 |
1353 | |
1354 | M |
1355 | Media Type |
1356 | multipart/byteranges 18, 21 |
1357 | multipart/x-byteranges 19 |
1358 | multipart/byteranges Media Type 18, 21 |
1359 | multipart/x-byteranges Media Type 21 |
1360 | |
1361 | R |
1362 | Range header field 8 |
1363 | |
1364 | Authors' Addresses |
1365 | |
1366 | Roy T. Fielding (editor) |
1367 | Adobe Systems Incorporated |
1368 | 345 Park Ave |
1369 | San Jose, CA 95110 |
1370 | USA |
1371 | |
1372 | EMail: fielding@gbiv.com |
1373 | URI: http://roy.gbiv.com/ |
1374 | |
1375 | |
1376 | Yves Lafon (editor) |
1377 | World Wide Web Consortium |
1378 | W3C / ERCIM |
1379 | 2004, rte des Lucioles |
1380 | Sophia-Antipolis, AM 06902 |
1381 | France |
1382 | |
1383 | EMail: ylafon@w3.org |
1384 | URI: http://www.raubacapeu.net/people/yves/ |
1385 | |
1386 | |
1387 | Julian F. Reschke (editor) |
1388 | greenbytes GmbH |
1389 | Hafenweg 16 |
1390 | Muenster, NW 48155 |
1391 | Germany |
1392 | |
1393 | EMail: julian.reschke@greenbytes.de |
1394 | URI: http://greenbytes.de/tech/webdav/ |
1395 | |
1396 | |
1397 | |
1398 | |
1399 | |
1400 | |
1401 | |
1402 | Fielding, et al. Standards Track [Page 25] |