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