source: draft-ietf-httpbis/latest/p5-range.xml @ 95

Last change on this file since 95 was 95, checked in by julian.reschke@…, 12 years ago

List Yves Lafon & Julian Reschke as Editors everywhere, remove specific ack for Julian.

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