1 | |
---|
2 | |
---|
3 | |
---|
4 | Network Working Group R. Fielding, Ed. |
---|
5 | Internet-Draft Day Software |
---|
6 | Obsoletes: 2068, 2616 J. Gettys |
---|
7 | (if approved) One Laptop per Child |
---|
8 | Intended status: Standards Track J. Mogul |
---|
9 | Expires: June 19, 2008 HP |
---|
10 | H. Frystyk |
---|
11 | Microsoft |
---|
12 | L. Masinter |
---|
13 | Adobe Systems |
---|
14 | P. Leach |
---|
15 | Microsoft |
---|
16 | T. Berners-Lee |
---|
17 | W3C/MIT |
---|
18 | December 17, 2007 |
---|
19 | |
---|
20 | |
---|
21 | HTTP/1.1, part 5: Range Requests and Partial Responses |
---|
22 | draft-ietf-httpbis-p5-range-00 |
---|
23 | |
---|
24 | Status of this Memo |
---|
25 | |
---|
26 | By submitting this Internet-Draft, each author represents that any |
---|
27 | applicable patent or other IPR claims of which he or she is aware |
---|
28 | have been or will be disclosed, and any of which he or she becomes |
---|
29 | aware will be disclosed, in accordance with Section 6 of BCP 79. |
---|
30 | |
---|
31 | Internet-Drafts are working documents of the Internet Engineering |
---|
32 | Task Force (IETF), its areas, and its working groups. Note that |
---|
33 | other groups may also distribute working documents as Internet- |
---|
34 | Drafts. |
---|
35 | |
---|
36 | Internet-Drafts are draft documents valid for a maximum of six months |
---|
37 | and may be updated, replaced, or obsoleted by other documents at any |
---|
38 | time. It is inappropriate to use Internet-Drafts as reference |
---|
39 | material or to cite them other than as "work in progress." |
---|
40 | |
---|
41 | The list of current Internet-Drafts can be accessed at |
---|
42 | http://www.ietf.org/ietf/1id-abstracts.txt. |
---|
43 | |
---|
44 | The list of Internet-Draft Shadow Directories can be accessed at |
---|
45 | http://www.ietf.org/shadow.html. |
---|
46 | |
---|
47 | This Internet-Draft will expire on June 19, 2008. |
---|
48 | |
---|
49 | Copyright Notice |
---|
50 | |
---|
51 | Copyright (C) The IETF Trust (2007). |
---|
52 | |
---|
53 | |
---|
54 | |
---|
55 | Fielding, et al. Expires June 19, 2008 [Page 1] |
---|
56 | |
---|
57 | Internet-Draft HTTP/1.1 December 2007 |
---|
58 | |
---|
59 | |
---|
60 | Abstract |
---|
61 | |
---|
62 | The Hypertext Transfer Protocol (HTTP) is an application-level |
---|
63 | protocol for distributed, collaborative, hypermedia information |
---|
64 | systems. HTTP has been in use by the World Wide Web global |
---|
65 | information initiative since 1990. This document is Part 5 of the |
---|
66 | seven-part specification that defines the protocol referred to as |
---|
67 | "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines |
---|
68 | range-specific requests and the rules for constructing and combining |
---|
69 | responses to those requests. |
---|
70 | |
---|
71 | Editorial Note (To be removed by RFC Editor) |
---|
72 | |
---|
73 | This version of the HTTP specification contains only minimal |
---|
74 | editorial changes from [RFC2616] (abstract, introductory paragraph, |
---|
75 | and authors' addresses). All other changes are due to partitioning |
---|
76 | the original into seven mostly independent parts. The intent is for |
---|
77 | readers of future drafts to able to use draft 00 as the basis for |
---|
78 | comparison when the WG makes later changes to the specification text. |
---|
79 | This draft will shortly be followed by draft 01 (containing the first |
---|
80 | round of changes that have already been agreed to on the mailing |
---|
81 | list). There is no point in reviewing this draft other than to |
---|
82 | verify that the partitioning has been done correctly. Roy T. |
---|
83 | Fielding, Yves Lafon, and Julian Reschke will be the editors after |
---|
84 | draft 00 is submitted. |
---|
85 | |
---|
86 | Discussion of this draft should take place on the HTTPBIS working |
---|
87 | group mailing list (ietf-http-wg@w3.org). The current issues list is |
---|
88 | at <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/> and |
---|
89 | related documents (including fancy diffs) can be found at |
---|
90 | <http://www3.tools.ietf.org/wg/httpbis/>. |
---|
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 June 19, 2008 [Page 2] |
---|
112 | |
---|
113 | Internet-Draft HTTP/1.1 December 2007 |
---|
114 | |
---|
115 | |
---|
116 | Table of Contents |
---|
117 | |
---|
118 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 |
---|
119 | 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 4 |
---|
120 | 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 4 |
---|
121 | 3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 4 |
---|
122 | 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 5 |
---|
123 | 4. Combining Byte Ranges . . . . . . . . . . . . . . . . . . . . 5 |
---|
124 | 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 6 |
---|
125 | 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 6 |
---|
126 | 5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 7 |
---|
127 | 5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 9 |
---|
128 | 5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 9 |
---|
129 | 5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 9 |
---|
130 | 5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 11 |
---|
131 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 |
---|
132 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 |
---|
133 | 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 |
---|
134 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 |
---|
135 | Appendix A. Internet Media Type multipart/byteranges . . . . . . 13 |
---|
136 | Appendix B. Changes from RFC 2068 . . . . . . . . . . . . . . . . 14 |
---|
137 | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 |
---|
138 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 |
---|
139 | Intellectual Property and Copyright Statements . . . . . . . . . . 18 |
---|
140 | |
---|
141 | |
---|
142 | |
---|
143 | |
---|
144 | |
---|
145 | |
---|
146 | |
---|
147 | |
---|
148 | |
---|
149 | |
---|
150 | |
---|
151 | |
---|
152 | |
---|
153 | |
---|
154 | |
---|
155 | |
---|
156 | |
---|
157 | |
---|
158 | |
---|
159 | |
---|
160 | |
---|
161 | |
---|
162 | |
---|
163 | |
---|
164 | |
---|
165 | |
---|
166 | |
---|
167 | Fielding, et al. Expires June 19, 2008 [Page 3] |
---|
168 | |
---|
169 | Internet-Draft HTTP/1.1 December 2007 |
---|
170 | |
---|
171 | |
---|
172 | 1. Introduction |
---|
173 | |
---|
174 | This document will define aspects of HTTP related to range requests, |
---|
175 | partial responses, and the multipart/byteranges media type. Right |
---|
176 | now it only includes the extracted relevant sections of RFC 2616 |
---|
177 | [RFC2616] without edit. |
---|
178 | |
---|
179 | |
---|
180 | 2. Range Units |
---|
181 | |
---|
182 | HTTP/1.1 allows a client to request that only part (a range of) the |
---|
183 | response entity be included within the response. HTTP/1.1 uses range |
---|
184 | units in the Range (Section 5.4) and Content-Range (Section 5.2) |
---|
185 | header fields. An entity can be broken down into subranges according |
---|
186 | to various structural units. |
---|
187 | |
---|
188 | range-unit = bytes-unit | other-range-unit |
---|
189 | bytes-unit = "bytes" |
---|
190 | other-range-unit = token |
---|
191 | |
---|
192 | The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 |
---|
193 | implementations MAY ignore ranges specified using other units. |
---|
194 | |
---|
195 | HTTP/1.1 has been designed to allow implementations of applications |
---|
196 | that do not depend on knowledge of ranges. |
---|
197 | |
---|
198 | |
---|
199 | 3. Status Code Definitions |
---|
200 | |
---|
201 | 3.1. 206 Partial Content |
---|
202 | |
---|
203 | The server has fulfilled the partial GET request for the resource. |
---|
204 | The request MUST have included a Range header field (Section 5.4) |
---|
205 | indicating the desired range, and MAY have included an If-Range |
---|
206 | header field (Section 5.3) to make the request conditional. |
---|
207 | |
---|
208 | The response MUST include the following header fields: |
---|
209 | |
---|
210 | o Either a Content-Range header field (Section 5.2) indicating the |
---|
211 | range included with this response, or a multipart/byteranges |
---|
212 | Content-Type including Content-Range fields for each part. If a |
---|
213 | Content-Length header field is present in the response, its value |
---|
214 | MUST match the actual number of OCTETs transmitted in the message- |
---|
215 | body. |
---|
216 | |
---|
217 | o Date |
---|
218 | |
---|
219 | |
---|
220 | |
---|
221 | |
---|
222 | |
---|
223 | Fielding, et al. Expires June 19, 2008 [Page 4] |
---|
224 | |
---|
225 | Internet-Draft HTTP/1.1 December 2007 |
---|
226 | |
---|
227 | |
---|
228 | o ETag and/or Content-Location, if the header would have been sent |
---|
229 | in a 200 response to the same request |
---|
230 | |
---|
231 | o Expires, Cache-Control, and/or Vary, if the field-value might |
---|
232 | differ from that sent in any previous response for the same |
---|
233 | variant |
---|
234 | |
---|
235 | If the 206 response is the result of an If-Range request that used a |
---|
236 | strong cache validator (see Section 4 of [Part4]), the response |
---|
237 | SHOULD NOT include other entity-headers. If the response is the |
---|
238 | result of an If-Range request that used a weak validator, the |
---|
239 | response MUST NOT include other entity-headers; this prevents |
---|
240 | inconsistencies between cached entity-bodies and updated headers. |
---|
241 | Otherwise, the response MUST include all of the entity-headers that |
---|
242 | would have been returned with a 200 (OK) response to the same |
---|
243 | request. |
---|
244 | |
---|
245 | A cache MUST NOT combine a 206 response with other previously cached |
---|
246 | content if the ETag or Last-Modified headers do not match exactly, |
---|
247 | see 4. |
---|
248 | |
---|
249 | A cache that does not support the Range and Content-Range headers |
---|
250 | MUST NOT cache 206 (Partial) responses. |
---|
251 | |
---|
252 | 3.2. 416 Requested Range Not Satisfiable |
---|
253 | |
---|
254 | A server SHOULD return a response with this status code if a request |
---|
255 | included a Range request-header field (Section 5.4), and none of the |
---|
256 | range-specifier values in this field overlap the current extent of |
---|
257 | the selected resource, and the request did not include an If-Range |
---|
258 | request-header field. (For byte-ranges, this means that the first- |
---|
259 | byte-pos of all of the byte-range-spec values were greater than the |
---|
260 | current length of the selected resource.) |
---|
261 | |
---|
262 | When this status code is returned for a byte-range request, the |
---|
263 | response SHOULD include a Content-Range entity-header field |
---|
264 | specifying the current length of the selected resource (see |
---|
265 | Section 5.2). This response MUST NOT use the multipart/byteranges |
---|
266 | content-type. |
---|
267 | |
---|
268 | |
---|
269 | 4. Combining Byte Ranges |
---|
270 | |
---|
271 | A response might transfer only a subrange of the bytes of an entity- |
---|
272 | body, either because the request included one or more Range |
---|
273 | specifications, or because a connection was broken prematurely. |
---|
274 | After several such transfers, a cache might have received several |
---|
275 | ranges of the same entity-body. |
---|
276 | |
---|
277 | |
---|
278 | |
---|
279 | Fielding, et al. Expires June 19, 2008 [Page 5] |
---|
280 | |
---|
281 | Internet-Draft HTTP/1.1 December 2007 |
---|
282 | |
---|
283 | |
---|
284 | If a cache has a stored non-empty set of subranges for an entity, and |
---|
285 | an incoming response transfers another subrange, the cache MAY |
---|
286 | combine the new subrange with the existing set if both the following |
---|
287 | conditions are met: |
---|
288 | |
---|
289 | o Both the incoming response and the cache entry have a cache |
---|
290 | validator. |
---|
291 | |
---|
292 | o The two cache validators match using the strong comparison |
---|
293 | function (see Section 4 of [Part4]). |
---|
294 | |
---|
295 | If either requirement is not met, the cache MUST use only the most |
---|
296 | recent partial response (based on the Date values transmitted with |
---|
297 | every response, and using the incoming response if these values are |
---|
298 | equal or missing), and MUST discard the other partial information. |
---|
299 | |
---|
300 | |
---|
301 | 5. Header Field Definitions |
---|
302 | |
---|
303 | This section defines the syntax and semantics of all standard |
---|
304 | HTTP/1.1 header fields. For entity-header fields, both sender and |
---|
305 | recipient refer to either the client or the server, depending on who |
---|
306 | sends and who receives the entity. |
---|
307 | |
---|
308 | 5.1. Accept-Ranges |
---|
309 | |
---|
310 | The Accept-Ranges response-header field allows the server to indicate |
---|
311 | its acceptance of range requests for a resource: |
---|
312 | |
---|
313 | Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges |
---|
314 | acceptable-ranges = 1#range-unit | "none" |
---|
315 | |
---|
316 | Origin servers that accept byte-range requests MAY send |
---|
317 | |
---|
318 | Accept-Ranges: bytes |
---|
319 | |
---|
320 | but are not required to do so. Clients MAY generate byte-range |
---|
321 | requests without having received this header for the resource |
---|
322 | involved. Range units are defined in Section 2. |
---|
323 | |
---|
324 | Servers that do not accept any kind of range request for a resource |
---|
325 | MAY send |
---|
326 | |
---|
327 | Accept-Ranges: none |
---|
328 | |
---|
329 | to advise the client not to attempt a range request. |
---|
330 | |
---|
331 | |
---|
332 | |
---|
333 | |
---|
334 | |
---|
335 | Fielding, et al. Expires June 19, 2008 [Page 6] |
---|
336 | |
---|
337 | Internet-Draft HTTP/1.1 December 2007 |
---|
338 | |
---|
339 | |
---|
340 | 5.2. Content-Range |
---|
341 | |
---|
342 | The Content-Range entity-header is sent with a partial entity-body to |
---|
343 | specify where in the full entity-body the partial body should be |
---|
344 | applied. Range units are defined in Section 2. |
---|
345 | |
---|
346 | Content-Range = "Content-Range" ":" content-range-spec |
---|
347 | |
---|
348 | content-range-spec = byte-content-range-spec |
---|
349 | byte-content-range-spec = bytes-unit SP |
---|
350 | byte-range-resp-spec "/" |
---|
351 | ( instance-length | "*" ) |
---|
352 | |
---|
353 | byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) |
---|
354 | | "*" |
---|
355 | instance-length = 1*DIGIT |
---|
356 | |
---|
357 | The header SHOULD indicate the total length of the full entity-body, |
---|
358 | unless this length is unknown or difficult to determine. The |
---|
359 | asterisk "*" character means that the instance-length is unknown at |
---|
360 | the time when the response was generated. |
---|
361 | |
---|
362 | Unlike byte-ranges-specifier values (see Section 5.4.1), a byte- |
---|
363 | range-resp-spec MUST only specify one range, and MUST contain |
---|
364 | absolute byte positions for both the first and last byte of the |
---|
365 | range. |
---|
366 | |
---|
367 | A byte-content-range-spec with a byte-range-resp-spec whose last- |
---|
368 | byte-pos value is less than its first-byte-pos value, or whose |
---|
369 | instance-length value is less than or equal to its last-byte-pos |
---|
370 | value, is invalid. The recipient of an invalid byte-content-range- |
---|
371 | spec MUST ignore it and any content transferred along with it. |
---|
372 | |
---|
373 | A server sending a response with status code 416 (Requested range not |
---|
374 | satisfiable) SHOULD include a Content-Range field with a byte-range- |
---|
375 | resp-spec of "*". The instance-length specifies the current length |
---|
376 | of the selected resource. A response with status code 206 (Partial |
---|
377 | Content) MUST NOT include a Content-Range field with a byte-range- |
---|
378 | resp-spec of "*". |
---|
379 | |
---|
380 | Examples of byte-content-range-spec values, assuming that the entity |
---|
381 | contains a total of 1234 bytes: |
---|
382 | |
---|
383 | o The first 500 bytes: |
---|
384 | |
---|
385 | bytes 0-499/1234 |
---|
386 | |
---|
387 | |
---|
388 | |
---|
389 | |
---|
390 | |
---|
391 | Fielding, et al. Expires June 19, 2008 [Page 7] |
---|
392 | |
---|
393 | Internet-Draft HTTP/1.1 December 2007 |
---|
394 | |
---|
395 | |
---|
396 | o The second 500 bytes: |
---|
397 | |
---|
398 | bytes 500-999/1234 |
---|
399 | |
---|
400 | o All except for the first 500 bytes: |
---|
401 | |
---|
402 | bytes 500-1233/1234 |
---|
403 | |
---|
404 | o The last 500 bytes: |
---|
405 | |
---|
406 | bytes 734-1233/1234 |
---|
407 | |
---|
408 | When an HTTP message includes the content of a single range (for |
---|
409 | example, a response to a request for a single range, or to a request |
---|
410 | for a set of ranges that overlap without any holes), this content is |
---|
411 | transmitted with a Content-Range header, and a Content-Length header |
---|
412 | showing the number of bytes actually transferred. For example, |
---|
413 | |
---|
414 | HTTP/1.1 206 Partial content |
---|
415 | Date: Wed, 15 Nov 1995 06:25:24 GMT |
---|
416 | Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT |
---|
417 | Content-Range: bytes 21010-47021/47022 |
---|
418 | Content-Length: 26012 |
---|
419 | Content-Type: image/gif |
---|
420 | |
---|
421 | When an HTTP message includes the content of multiple ranges (for |
---|
422 | example, a response to a request for multiple non-overlapping |
---|
423 | ranges), these are transmitted as a multipart message. The multipart |
---|
424 | media type used for this purpose is "multipart/byteranges" as defined |
---|
425 | in Appendix A. See Appendix B for a compatibility issue. |
---|
426 | |
---|
427 | A response to a request for a single range MUST NOT be sent using the |
---|
428 | multipart/byteranges media type. A response to a request for |
---|
429 | multiple ranges, whose result is a single range, MAY be sent as a |
---|
430 | multipart/byteranges media type with one part. A client that cannot |
---|
431 | decode a multipart/byteranges message MUST NOT ask for multiple byte- |
---|
432 | ranges in a single request. |
---|
433 | |
---|
434 | When a client requests multiple byte-ranges in one request, the |
---|
435 | server SHOULD return them in the order that they appeared in the |
---|
436 | request. |
---|
437 | |
---|
438 | If the server ignores a byte-range-spec because it is syntactically |
---|
439 | invalid, the server SHOULD treat the request as if the invalid Range |
---|
440 | header field did not exist. (Normally, this means return a 200 |
---|
441 | response containing the full entity). |
---|
442 | |
---|
443 | If the server receives a request (other than one including an If- |
---|
444 | |
---|
445 | |
---|
446 | |
---|
447 | Fielding, et al. Expires June 19, 2008 [Page 8] |
---|
448 | |
---|
449 | Internet-Draft HTTP/1.1 December 2007 |
---|
450 | |
---|
451 | |
---|
452 | Range request-header field) with an unsatisfiable Range request- |
---|
453 | header field (that is, all of whose byte-range-spec values have a |
---|
454 | first-byte-pos value greater than the current length of the selected |
---|
455 | resource), it SHOULD return a response code of 416 (Requested range |
---|
456 | not satisfiable) (Section 3.2). |
---|
457 | |
---|
458 | Note: clients cannot depend on servers to send a 416 (Requested |
---|
459 | range not satisfiable) response instead of a 200 (OK) response for |
---|
460 | an unsatisfiable Range request-header, since not all servers |
---|
461 | implement this request-header. |
---|
462 | |
---|
463 | 5.3. If-Range |
---|
464 | |
---|
465 | If a client has a partial copy of an entity in its cache, and wishes |
---|
466 | to have an up-to-date copy of the entire entity in its cache, it |
---|
467 | could use the Range request-header with a conditional GET (using |
---|
468 | either or both of If-Unmodified-Since and If-Match.) However, if the |
---|
469 | condition fails because the entity has been modified, the client |
---|
470 | would then have to make a second request to obtain the entire current |
---|
471 | entity-body. |
---|
472 | |
---|
473 | The If-Range header allows a client to "short-circuit" the second |
---|
474 | request. Informally, its meaning is `if the entity is unchanged, |
---|
475 | send me the part(s) that I am missing; otherwise, send me the entire |
---|
476 | new entity'. |
---|
477 | |
---|
478 | If-Range = "If-Range" ":" ( entity-tag | HTTP-date ) |
---|
479 | |
---|
480 | If the client has no entity tag for an entity, but does have a Last- |
---|
481 | Modified date, it MAY use that date in an If-Range header. (The |
---|
482 | server can distinguish between a valid HTTP-date and any form of |
---|
483 | entity-tag by examining no more than two characters.) The If-Range |
---|
484 | header SHOULD only be used together with a Range header, and MUST be |
---|
485 | ignored if the request does not include a Range header, or if the |
---|
486 | server does not support the sub-range operation. |
---|
487 | |
---|
488 | If the entity tag given in the If-Range header matches the current |
---|
489 | entity tag for the entity, then the server SHOULD provide the |
---|
490 | specified sub-range of the entity using a 206 (Partial content) |
---|
491 | response. If the entity tag does not match, then the server SHOULD |
---|
492 | return the entire entity using a 200 (OK) response. |
---|
493 | |
---|
494 | 5.4. Range |
---|
495 | |
---|
496 | 5.4.1. Byte Ranges |
---|
497 | |
---|
498 | Since all HTTP entities are represented in HTTP messages as sequences |
---|
499 | of bytes, the concept of a byte range is meaningful for any HTTP |
---|
500 | |
---|
501 | |
---|
502 | |
---|
503 | Fielding, et al. Expires June 19, 2008 [Page 9] |
---|
504 | |
---|
505 | Internet-Draft HTTP/1.1 December 2007 |
---|
506 | |
---|
507 | |
---|
508 | entity. (However, not all clients and servers need to support byte- |
---|
509 | range operations.) |
---|
510 | |
---|
511 | Byte range specifications in HTTP apply to the sequence of bytes in |
---|
512 | the entity-body (not necessarily the same as the message-body). |
---|
513 | |
---|
514 | A byte range operation MAY specify a single range of bytes, or a set |
---|
515 | of ranges within a single entity. |
---|
516 | |
---|
517 | ranges-specifier = byte-ranges-specifier |
---|
518 | byte-ranges-specifier = bytes-unit "=" byte-range-set |
---|
519 | byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec ) |
---|
520 | byte-range-spec = first-byte-pos "-" [last-byte-pos] |
---|
521 | first-byte-pos = 1*DIGIT |
---|
522 | last-byte-pos = 1*DIGIT |
---|
523 | |
---|
524 | The first-byte-pos value in a byte-range-spec gives the byte-offset |
---|
525 | of the first byte in a range. The last-byte-pos value gives the |
---|
526 | byte-offset of the last byte in the range; that is, the byte |
---|
527 | positions specified are inclusive. Byte offsets start at zero. |
---|
528 | |
---|
529 | If the last-byte-pos value is present, it MUST be greater than or |
---|
530 | equal to the first-byte-pos in that byte-range-spec, or the byte- |
---|
531 | range-spec is syntactically invalid. The recipient of a byte-range- |
---|
532 | set that includes one or more syntactically invalid byte-range-spec |
---|
533 | values MUST ignore the header field that includes that byte-range- |
---|
534 | set. |
---|
535 | |
---|
536 | If the last-byte-pos value is absent, or if the value is greater than |
---|
537 | or equal to the current length of the entity-body, last-byte-pos is |
---|
538 | taken to be equal to one less than the current length of the entity- |
---|
539 | body in bytes. |
---|
540 | |
---|
541 | By its choice of last-byte-pos, a client can limit the number of |
---|
542 | bytes retrieved without knowing the size of the entity. |
---|
543 | |
---|
544 | suffix-byte-range-spec = "-" suffix-length |
---|
545 | suffix-length = 1*DIGIT |
---|
546 | |
---|
547 | A suffix-byte-range-spec is used to specify the suffix of the entity- |
---|
548 | body, of a length given by the suffix-length value. (That is, this |
---|
549 | form specifies the last N bytes of an entity-body.) If the entity is |
---|
550 | shorter than the specified suffix-length, the entire entity-body is |
---|
551 | used. |
---|
552 | |
---|
553 | If a syntactically valid byte-range-set includes at least one byte- |
---|
554 | range-spec whose first-byte-pos is less than the current length of |
---|
555 | the entity-body, or at least one suffix-byte-range-spec with a non- |
---|
556 | |
---|
557 | |
---|
558 | |
---|
559 | Fielding, et al. Expires June 19, 2008 [Page 10] |
---|
560 | |
---|
561 | Internet-Draft HTTP/1.1 December 2007 |
---|
562 | |
---|
563 | |
---|
564 | zero suffix-length, then the byte-range-set is satisfiable. |
---|
565 | Otherwise, the byte-range-set is unsatisfiable. If the byte-range- |
---|
566 | set is unsatisfiable, the server SHOULD return a response with a |
---|
567 | status of 416 (Requested range not satisfiable). Otherwise, the |
---|
568 | server SHOULD return a response with a status of 206 (Partial |
---|
569 | Content) containing the satisfiable ranges of the entity-body. |
---|
570 | |
---|
571 | Examples of byte-ranges-specifier values (assuming an entity-body of |
---|
572 | length 10000): |
---|
573 | |
---|
574 | o The first 500 bytes (byte offsets 0-499, inclusive): bytes=0-499 |
---|
575 | |
---|
576 | o The second 500 bytes (byte offsets 500-999, inclusive): bytes=500- |
---|
577 | 999 |
---|
578 | |
---|
579 | o The final 500 bytes (byte offsets 9500-9999, inclusive): bytes=- |
---|
580 | 500 |
---|
581 | |
---|
582 | o Or bytes=9500- |
---|
583 | |
---|
584 | o The first and last bytes only (bytes 0 and 9999): bytes=0-0,-1 |
---|
585 | |
---|
586 | o Several legal but not canonical specifications of the second 500 |
---|
587 | bytes (byte offsets 500-999, inclusive): |
---|
588 | bytes=500-600,601-999 |
---|
589 | bytes=500-700,601-999 |
---|
590 | |
---|
591 | 5.4.2. Range Retrieval Requests |
---|
592 | |
---|
593 | HTTP retrieval requests using conditional or unconditional GET |
---|
594 | methods MAY request one or more sub-ranges of the entity, instead of |
---|
595 | the entire entity, using the Range request header, which applies to |
---|
596 | the entity returned as the result of the request: |
---|
597 | |
---|
598 | Range = "Range" ":" ranges-specifier |
---|
599 | |
---|
600 | A server MAY ignore the Range header. However, HTTP/1.1 origin |
---|
601 | servers and intermediate caches ought to support byte ranges when |
---|
602 | possible, since Range supports efficient recovery from partially |
---|
603 | failed transfers, and supports efficient partial retrieval of large |
---|
604 | entities. |
---|
605 | |
---|
606 | If the server supports the Range header and the specified range or |
---|
607 | ranges are appropriate for the entity: |
---|
608 | |
---|
609 | o The presence of a Range header in an unconditional GET modifies |
---|
610 | what is returned if the GET is otherwise successful. In other |
---|
611 | words, the response carries a status code of 206 (Partial Content) |
---|
612 | |
---|
613 | |
---|
614 | |
---|
615 | Fielding, et al. Expires June 19, 2008 [Page 11] |
---|
616 | |
---|
617 | Internet-Draft HTTP/1.1 December 2007 |
---|
618 | |
---|
619 | |
---|
620 | instead of 200 (OK). |
---|
621 | |
---|
622 | o The presence of a Range header in a conditional GET (a request |
---|
623 | using one or both of If-Modified-Since and If-None-Match, or one |
---|
624 | or both of If-Unmodified-Since and If-Match) modifies what is |
---|
625 | returned if the GET is otherwise successful and the condition is |
---|
626 | true. It does not affect the 304 (Not Modified) response returned |
---|
627 | if the conditional is false. |
---|
628 | |
---|
629 | In some cases, it might be more appropriate to use the If-Range |
---|
630 | header (see Section 5.3) in addition to the Range header. |
---|
631 | |
---|
632 | If a proxy that supports ranges receives a Range request, forwards |
---|
633 | the request to an inbound server, and receives an entire entity in |
---|
634 | reply, it SHOULD only return the requested range to its client. It |
---|
635 | SHOULD store the entire received response in its cache if that is |
---|
636 | consistent with its cache allocation policies. |
---|
637 | |
---|
638 | |
---|
639 | 6. IANA Considerations |
---|
640 | |
---|
641 | TBD. |
---|
642 | |
---|
643 | |
---|
644 | 7. Security Considerations |
---|
645 | |
---|
646 | No additional security considerations have been identified beyond |
---|
647 | those applicable to HTTP in general [Part1]. |
---|
648 | |
---|
649 | |
---|
650 | 8. Acknowledgments |
---|
651 | |
---|
652 | Most of the specification of ranges is based on work originally done |
---|
653 | by Ari Luotonen and John Franks, with additional input from Steve |
---|
654 | Zilles. |
---|
655 | |
---|
656 | Based on an XML translation of RFC 2616 by Julian Reschke. |
---|
657 | |
---|
658 | |
---|
659 | 9. References |
---|
660 | |
---|
661 | [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
---|
662 | Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1, |
---|
663 | part 1: URIs, Connections, and Message Parsing", |
---|
664 | draft-fielding-p1-messaging-00 (work in progress), |
---|
665 | December 2007. |
---|
666 | |
---|
667 | [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
---|
668 | |
---|
669 | |
---|
670 | |
---|
671 | Fielding, et al. Expires June 19, 2008 [Page 12] |
---|
672 | |
---|
673 | Internet-Draft HTTP/1.1 December 2007 |
---|
674 | |
---|
675 | |
---|
676 | Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1, |
---|
677 | part 4: Conditional Requests", |
---|
678 | draft-fielding-p4-conditional-00 (work in progress), |
---|
679 | December 2007. |
---|
680 | |
---|
681 | [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail |
---|
682 | Extensions (MIME) Part Two: Media Types", RFC 2046, |
---|
683 | November 1996. |
---|
684 | |
---|
685 | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |
---|
686 | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |
---|
687 | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |
---|
688 | |
---|
689 | |
---|
690 | Appendix A. Internet Media Type multipart/byteranges |
---|
691 | |
---|
692 | When an HTTP 206 (Partial Content) response message includes the |
---|
693 | content of multiple ranges (a response to a request for multiple non- |
---|
694 | overlapping ranges), these are transmitted as a multipart message- |
---|
695 | body. The media type for this purpose is called "multipart/ |
---|
696 | byteranges". |
---|
697 | |
---|
698 | The multipart/byteranges media type includes two or more parts, each |
---|
699 | with its own Content-Type and Content-Range fields. The required |
---|
700 | boundary parameter specifies the boundary string used to separate |
---|
701 | each body-part. |
---|
702 | |
---|
703 | Media Type name: multipart |
---|
704 | |
---|
705 | Media subtype name: byteranges |
---|
706 | |
---|
707 | Required parameters: boundary |
---|
708 | |
---|
709 | Optional parameters: none |
---|
710 | |
---|
711 | Encoding considerations: only "7bit", "8bit", or "binary" are |
---|
712 | permitted |
---|
713 | |
---|
714 | Security considerations: none |
---|
715 | |
---|
716 | |
---|
717 | |
---|
718 | |
---|
719 | |
---|
720 | |
---|
721 | |
---|
722 | |
---|
723 | |
---|
724 | |
---|
725 | |
---|
726 | |
---|
727 | Fielding, et al. Expires June 19, 2008 [Page 13] |
---|
728 | |
---|
729 | Internet-Draft HTTP/1.1 December 2007 |
---|
730 | |
---|
731 | |
---|
732 | For example: |
---|
733 | |
---|
734 | HTTP/1.1 206 Partial Content |
---|
735 | Date: Wed, 15 Nov 1995 06:25:24 GMT |
---|
736 | Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT |
---|
737 | Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES |
---|
738 | |
---|
739 | --THIS_STRING_SEPARATES |
---|
740 | Content-type: application/pdf |
---|
741 | Content-range: bytes 500-999/8000 |
---|
742 | |
---|
743 | ...the first range... |
---|
744 | --THIS_STRING_SEPARATES |
---|
745 | Content-type: application/pdf |
---|
746 | Content-range: bytes 7000-7999/8000 |
---|
747 | |
---|
748 | ...the second range |
---|
749 | --THIS_STRING_SEPARATES-- |
---|
750 | |
---|
751 | Notes: |
---|
752 | |
---|
753 | 1. Additional CRLFs may precede the first boundary string in the |
---|
754 | entity. |
---|
755 | |
---|
756 | 2. Although RFC 2046 [RFC2046] permits the boundary string to be |
---|
757 | quoted, some existing implementations handle a quoted boundary |
---|
758 | string incorrectly. |
---|
759 | |
---|
760 | 3. A number of browsers and servers were coded to an early draft of |
---|
761 | the byteranges specification to use a media type of multipart/ |
---|
762 | x-byteranges, which is almost, but not quite compatible with the |
---|
763 | version documented in HTTP/1.1. |
---|
764 | |
---|
765 | |
---|
766 | Appendix B. Changes from RFC 2068 |
---|
767 | |
---|
768 | There are situations where a server (especially a proxy) does not |
---|
769 | know the full length of a response but is capable of serving a |
---|
770 | byterange request. We therefore need a mechanism to allow byteranges |
---|
771 | with a content-range not indicating the full length of the message. |
---|
772 | (Section 5.2) |
---|
773 | |
---|
774 | Range request responses would become very verbose if all meta-data |
---|
775 | were always returned; by allowing the server to only send needed |
---|
776 | headers in a 206 response, this problem can be avoided. |
---|
777 | |
---|
778 | Fix problem with unsatisfiable range requests; there are two cases: |
---|
779 | syntactic problems, and range doesn't exist in the document. The 416 |
---|
780 | |
---|
781 | |
---|
782 | |
---|
783 | Fielding, et al. Expires June 19, 2008 [Page 14] |
---|
784 | |
---|
785 | Internet-Draft HTTP/1.1 December 2007 |
---|
786 | |
---|
787 | |
---|
788 | status code was needed to resolve this ambiguity needed to indicate |
---|
789 | an error for a byte range request that falls outside of the actual |
---|
790 | contents of a document. (Section 3.2, 5.2) |
---|
791 | |
---|
792 | |
---|
793 | Index |
---|
794 | |
---|
795 | 2 |
---|
796 | 206 Partial Content (status code) 4 |
---|
797 | |
---|
798 | 4 |
---|
799 | 416 Requested Range Not Satisfiable (status code) 5 |
---|
800 | |
---|
801 | A |
---|
802 | Accept-Ranges header 6 |
---|
803 | |
---|
804 | C |
---|
805 | Content-Range header 7 |
---|
806 | |
---|
807 | G |
---|
808 | Grammar |
---|
809 | Accept-Ranges 6 |
---|
810 | acceptable-ranges 6 |
---|
811 | byte-content-range-spec 7 |
---|
812 | byte-range-resp-spec 7 |
---|
813 | byte-range-set 10 |
---|
814 | byte-range-spec 10 |
---|
815 | byte-ranges-specifier 10 |
---|
816 | bytes-unit 4 |
---|
817 | Content-Range 7 |
---|
818 | content-range-spec 7 |
---|
819 | first-byte-pos 10 |
---|
820 | If-Range 9 |
---|
821 | instance-length 7 |
---|
822 | last-byte-pos 10 |
---|
823 | other-range-unit 4 |
---|
824 | Range 11 |
---|
825 | range-unit 4 |
---|
826 | ranges-specifier 10 |
---|
827 | suffix-byte-range-spec 10 |
---|
828 | suffix-length 10 |
---|
829 | |
---|
830 | H |
---|
831 | Headers |
---|
832 | Accept-Ranges 6 |
---|
833 | Content-Range 7 |
---|
834 | If-Range 9 |
---|
835 | Range 9 |
---|
836 | |
---|
837 | |
---|
838 | |
---|
839 | Fielding, et al. Expires June 19, 2008 [Page 15] |
---|
840 | |
---|
841 | Internet-Draft HTTP/1.1 December 2007 |
---|
842 | |
---|
843 | |
---|
844 | I |
---|
845 | If-Range header 9 |
---|
846 | |
---|
847 | M |
---|
848 | Media Type |
---|
849 | multipart/byteranges 13 |
---|
850 | multipart/x-byteranges 14 |
---|
851 | multipart/byteranges Media Type 13 |
---|
852 | multipart/x-byteranges Media Type 14 |
---|
853 | |
---|
854 | R |
---|
855 | Range header 9 |
---|
856 | |
---|
857 | S |
---|
858 | Status Codes |
---|
859 | 206 Partial Content 4 |
---|
860 | 416 Requested Range Not Satisfiable 5 |
---|
861 | |
---|
862 | |
---|
863 | Authors' Addresses |
---|
864 | |
---|
865 | Roy T. Fielding (editor) |
---|
866 | Day Software |
---|
867 | 23 Corporate Plaza DR, Suite 280 |
---|
868 | Newport Beach, CA 92660 |
---|
869 | USA |
---|
870 | |
---|
871 | Phone: +1-949-706-5300 |
---|
872 | Fax: +1-949-706-5305 |
---|
873 | Email: fielding@gbiv.com |
---|
874 | URI: http://roy.gbiv.com/ |
---|
875 | |
---|
876 | |
---|
877 | Jim Gettys |
---|
878 | One Laptop per Child |
---|
879 | 21 Oak Knoll Road |
---|
880 | Carlisle, MA 01741 |
---|
881 | USA |
---|
882 | |
---|
883 | Email: jg@laptop.org |
---|
884 | URI: http://www.laptop.org/ |
---|
885 | |
---|
886 | |
---|
887 | |
---|
888 | |
---|
889 | |
---|
890 | |
---|
891 | |
---|
892 | |
---|
893 | |
---|
894 | |
---|
895 | Fielding, et al. Expires June 19, 2008 [Page 16] |
---|
896 | |
---|
897 | Internet-Draft HTTP/1.1 December 2007 |
---|
898 | |
---|
899 | |
---|
900 | Jeffrey C. Mogul |
---|
901 | Hewlett-Packard Company |
---|
902 | HP Labs, Large Scale Systems Group |
---|
903 | 1501 Page Mill Road, MS 1177 |
---|
904 | Palo Alto, CA 94304 |
---|
905 | USA |
---|
906 | |
---|
907 | Email: JeffMogul@acm.org |
---|
908 | |
---|
909 | |
---|
910 | Henrik Frystyk Nielsen |
---|
911 | Microsoft Corporation |
---|
912 | 1 Microsoft Way |
---|
913 | Redmond, WA 98052 |
---|
914 | USA |
---|
915 | |
---|
916 | Email: henrikn@microsoft.com |
---|
917 | |
---|
918 | |
---|
919 | Larry Masinter |
---|
920 | Adobe Systems, Incorporated |
---|
921 | 345 Park Ave |
---|
922 | San Jose, CA 95110 |
---|
923 | USA |
---|
924 | |
---|
925 | Email: LMM@acm.org |
---|
926 | URI: http://larry.masinter.net/ |
---|
927 | |
---|
928 | |
---|
929 | Paul J. Leach |
---|
930 | Microsoft Corporation |
---|
931 | 1 Microsoft Way |
---|
932 | Redmond, WA 98052 |
---|
933 | |
---|
934 | Email: paulle@microsoft.com |
---|
935 | |
---|
936 | |
---|
937 | Tim Berners-Lee |
---|
938 | World Wide Web Consortium |
---|
939 | MIT Computer Science and Artificial Intelligence Laboratory |
---|
940 | The Stata Center, Building 32 |
---|
941 | 32 Vassar Street |
---|
942 | Cambridge, MA 02139 |
---|
943 | USA |
---|
944 | |
---|
945 | Email: timbl@w3.org |
---|
946 | URI: http://www.w3.org/People/Berners-Lee/ |
---|
947 | |
---|
948 | |
---|
949 | |
---|
950 | |
---|
951 | Fielding, et al. Expires June 19, 2008 [Page 17] |
---|
952 | |
---|
953 | Internet-Draft HTTP/1.1 December 2007 |
---|
954 | |
---|
955 | |
---|
956 | Full Copyright Statement |
---|
957 | |
---|
958 | Copyright (C) The IETF Trust (2007). |
---|
959 | |
---|
960 | This document is subject to the rights, licenses and restrictions |
---|
961 | contained in BCP 78, and except as set forth therein, the authors |
---|
962 | retain all their rights. |
---|
963 | |
---|
964 | This document and the information contained herein are provided on an |
---|
965 | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS |
---|
966 | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND |
---|
967 | THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS |
---|
968 | OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF |
---|
969 | THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED |
---|
970 | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. |
---|
971 | |
---|
972 | |
---|
973 | Intellectual Property |
---|
974 | |
---|
975 | The IETF takes no position regarding the validity or scope of any |
---|
976 | Intellectual Property Rights or other rights that might be claimed to |
---|
977 | pertain to the implementation or use of the technology described in |
---|
978 | this document or the extent to which any license under such rights |
---|
979 | might or might not be available; nor does it represent that it has |
---|
980 | made any independent effort to identify any such rights. Information |
---|
981 | on the procedures with respect to rights in RFC documents can be |
---|
982 | found in BCP 78 and BCP 79. |
---|
983 | |
---|
984 | Copies of IPR disclosures made to the IETF Secretariat and any |
---|
985 | assurances of licenses to be made available, or the result of an |
---|
986 | attempt made to obtain a general license or permission for the use of |
---|
987 | such proprietary rights by implementers or users of this |
---|
988 | specification can be obtained from the IETF on-line IPR repository at |
---|
989 | http://www.ietf.org/ipr. |
---|
990 | |
---|
991 | The IETF invites any interested party to bring to its attention any |
---|
992 | copyrights, patents or patent applications, or other proprietary |
---|
993 | rights that may cover technology that may be required to implement |
---|
994 | this standard. Please address the information to the IETF at |
---|
995 | ietf-ipr@ietf.org. |
---|
996 | |
---|
997 | |
---|
998 | Acknowledgment |
---|
999 | |
---|
1000 | Funding for the RFC Editor function is provided by the IETF |
---|
1001 | Administrative Support Activity (IASA). |
---|
1002 | |
---|
1003 | |
---|
1004 | |
---|
1005 | |
---|
1006 | |
---|
1007 | Fielding, et al. Expires June 19, 2008 [Page 18] |
---|
1008 | |
---|