source: draft-ietf-httpbis/11/draft-ietf-httpbis-p5-range-11.xml @ 973

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

prepare publication of -11 drafts on 2010-08-04.

  • Property svn:eol-style set to native
File size: 57.3 KB
Line 
1<?xml version="1.0" encoding="UTF-8"?>
2<!--
3    This XML document is the output of clean-for-DTD.xslt; a tool that strips
4    extensions to RFC2629(bis) from documents for processing with xml2rfc.
5-->
6<?xml-stylesheet type='text/xsl' href='../myxml2rfc.xslt'?>
7<?rfc toc="yes" ?>
8<?rfc symrefs="yes" ?>
9<?rfc sortrefs="yes" ?>
10<?rfc compact="yes"?>
11<?rfc subcompact="no" ?>
12<?rfc linkmailto="no" ?>
13<?rfc editing="no" ?>
14<?rfc comments="yes"?>
15<?rfc inline="yes"?>
16<?rfc rfcedstyle="yes"?>
17<!DOCTYPE rfc
18  PUBLIC "" "rfc2629.dtd">
19<rfc obsoletes="2616" category="std" ipr="pre5378Trust200902" docName="draft-ietf-httpbis-p5-range-11">
20<front>
21
22  <title abbrev="HTTP/1.1, Part 5">HTTP/1.1, part 5: Range Requests and Partial Responses</title>
23
24  <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
25    <organization abbrev="Day Software">Day Software</organization>
26    <address>
27      <postal>
28        <street>23 Corporate Plaza DR, Suite 280</street>
29        <city>Newport Beach</city>
30        <region>CA</region>
31        <code>92660</code>
32        <country>USA</country>
33      </postal>
34      <phone>+1-949-706-5300</phone>
35      <facsimile>+1-949-706-5305</facsimile>
36      <email>fielding@gbiv.com</email>
37      <uri>http://roy.gbiv.com/</uri>
38    </address>
39  </author>
40
41  <author initials="J." surname="Gettys" fullname="Jim Gettys">
42    <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization>
43    <address>
44      <postal>
45        <street>21 Oak Knoll Road</street>
46        <city>Carlisle</city>
47        <region>MA</region>
48        <code>01741</code>
49        <country>USA</country>
50      </postal>
51      <email>jg@freedesktop.org</email>
52      <uri>http://gettys.wordpress.com/</uri>
53    </address>
54  </author>
55 
56  <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
57    <organization abbrev="HP">Hewlett-Packard Company</organization>
58    <address>
59      <postal>
60        <street>HP Labs, Large Scale Systems Group</street>
61        <street>1501 Page Mill Road, MS 1177</street>
62        <city>Palo Alto</city>
63        <region>CA</region>
64        <code>94304</code>
65        <country>USA</country>
66      </postal>
67      <email>JeffMogul@acm.org</email>
68    </address>
69  </author>
70
71  <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
72    <organization abbrev="Microsoft">Microsoft Corporation</organization>
73    <address>
74      <postal>
75        <street>1 Microsoft Way</street>
76        <city>Redmond</city>
77        <region>WA</region>
78        <code>98052</code>
79        <country>USA</country>
80      </postal>
81      <email>henrikn@microsoft.com</email>
82    </address>
83  </author>
84
85  <author initials="L." surname="Masinter" fullname="Larry Masinter">
86    <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
87    <address>
88      <postal>
89        <street>345 Park Ave</street>
90        <city>San Jose</city>
91        <region>CA</region>
92        <code>95110</code>
93        <country>USA</country>
94      </postal>
95      <email>LMM@acm.org</email>
96      <uri>http://larry.masinter.net/</uri>
97    </address>
98  </author>
99 
100  <author initials="P." surname="Leach" fullname="Paul J. Leach">
101    <organization abbrev="Microsoft">Microsoft Corporation</organization>
102    <address>
103      <postal>
104        <street>1 Microsoft Way</street>
105        <city>Redmond</city>
106        <region>WA</region>
107        <code>98052</code>
108      </postal>
109      <email>paulle@microsoft.com</email>
110    </address>
111  </author>
112   
113  <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
114    <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
115    <address>
116      <postal>
117        <street>MIT Computer Science and Artificial Intelligence Laboratory</street>
118        <street>The Stata Center, Building 32</street>
119        <street>32 Vassar Street</street>
120        <city>Cambridge</city>
121        <region>MA</region>
122        <code>02139</code>
123        <country>USA</country>
124      </postal>
125      <email>timbl@w3.org</email>
126      <uri>http://www.w3.org/People/Berners-Lee/</uri>
127    </address>
128  </author>
129
130  <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
131    <organization abbrev="W3C">World Wide Web Consortium</organization>
132    <address>
133      <postal>
134        <street>W3C / ERCIM</street>
135        <street>2004, rte des Lucioles</street>
136        <city>Sophia-Antipolis</city>
137        <region>AM</region>
138        <code>06902</code>
139        <country>France</country>
140      </postal>
141      <email>ylafon@w3.org</email>
142      <uri>http://www.raubacapeu.net/people/yves/</uri>
143    </address>
144  </author>
145
146  <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
147    <organization abbrev="greenbytes">greenbytes GmbH</organization>
148    <address>
149      <postal>
150        <street>Hafenweg 16</street>
151        <city>Muenster</city><region>NW</region><code>48155</code>
152        <country>Germany</country>
153      </postal>
154      <phone>+49 251 2807760</phone>
155      <facsimile>+49 251 2807761</facsimile>
156      <email>julian.reschke@greenbytes.de</email>
157      <uri>http://greenbytes.de/tech/webdav/</uri>
158    </address>
159  </author>
160
161  <date month="August" year="2010" day="4"/>
162  <workgroup>HTTPbis Working Group</workgroup>
163
164<abstract>
165<t>
166   The Hypertext Transfer Protocol (HTTP) is an application-level
167   protocol for distributed, collaborative, hypermedia information
168   systems. HTTP has been in use by the World Wide Web global information
169   initiative since 1990. This document is Part 5 of the seven-part specification
170   that defines the protocol referred to as "HTTP/1.1" and, taken together,
171   obsoletes RFC 2616.  Part 5 defines range-specific requests and
172   the rules for constructing and combining responses to those requests.
173</t>
174</abstract>
175
176<note title="Editorial Note (To be removed by RFC Editor)">
177  <t>
178    Discussion of this draft should take place on the HTTPBIS working group
179    mailing list (ietf-http-wg@w3.org). The current issues list is
180    at <eref target="http://tools.ietf.org/wg/httpbis/trac/report/3"/>
181    and related documents (including fancy diffs) can be found at
182    <eref target="http://tools.ietf.org/wg/httpbis/"/>.
183  </t>
184  <t>
185    The changes in this draft are summarized in <xref target="changes.since.10"/>.
186  </t>
187</note>
188</front>
189<middle>
190<section title="Introduction" anchor="introduction">
191<t>
192   HTTP clients often encounter interrupted data transfers as a result
193   of cancelled requests or dropped connections.  When a cache has stored
194   a partial representation, it is desirable to request the remainder
195   of that representation in a subsequent request rather than transfer
196   the entire representation.
197   There are also a number of Web applications that benefit from being
198   able to request only a subset of a larger representation, such as a
199   single page of a very large document or only part of an image to be
200   rendered by a device with limited local storage.
201</t>
202<t>
203   This document defines HTTP/1.1 range requests,
204   partial responses, and the multipart/byteranges media type.
205   The protocol for range requests is an OPTIONAL feature of HTTP,
206   designed so resources or recipients that do not implement this feature
207   can respond as if it is a normal GET request without impacting
208   interoperability.  Partial responses are indicated by a distinct status
209   code to not be mistaken for full responses by intermediate caches
210   that might not implement the feature.
211</t>
212<t>
213   Although the HTTP range request mechanism is designed to allow for
214   extensible range types, this specification only defines requests for
215   byte ranges.
216</t>
217
218<section title="Requirements" anchor="intro.requirements">
219<t>
220   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
221   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
222   document are to be interpreted as described in <xref target="RFC2119"/>.
223</t>
224<t>
225   An implementation is not compliant if it fails to satisfy one or more
226   of the "MUST" or "REQUIRED" level requirements for the protocols it
227   implements. An implementation that satisfies all the "MUST" or "REQUIRED"
228   level and all the "SHOULD" level requirements for its protocols is said
229   to be "unconditionally compliant"; one that satisfies all the "MUST"
230   level requirements but not all the "SHOULD" level requirements for its
231   protocols is said to be "conditionally compliant".
232</t>
233</section>
234
235<section title="Syntax Notation" anchor="notation">
236 
237 
238 
239 
240 
241 
242 
243 
244 
245<t>
246  This specification uses the ABNF syntax defined in Section 1.2 of <xref target="Part1"/> (which
247  extends the syntax defined in <xref target="RFC5234"/> with a list rule).
248  <xref target="collected.abnf"/> shows the collected ABNF, with the list
249  rule expanded.
250</t>
251<t>
252  The following core rules are included by
253  reference, as defined in <xref target="RFC5234"/>, Appendix B.1:
254  ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls),
255  DIGIT (decimal 0-9), DQUOTE (double quote),
256  HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed),
257  OCTET (any 8-bit sequence of data), SP (space),
258  VCHAR (any visible USASCII character),
259  and WSP (whitespace).
260</t>
261
262<section title="Core Rules" anchor="core.rules">
263 
264 
265<t>
266  The core rules below are defined in Section 1.2.2 of <xref target="Part1"/>:
267</t>
268<figure><artwork type="abnf2616"><![CDATA[
269  token      = <token, defined in [Part1], Section 1.2.2>
270  OWS        = <OWS, defined in [Part1], Section 1.2.2>
271]]></artwork></figure>
272</section>
273
274<section title="ABNF Rules defined in other Parts of the Specification" anchor="abnf.dependencies">
275 
276 
277<t>
278  The ABNF rules below are defined in other parts:
279</t>
280<figure><artwork type="abnf2616"><![CDATA[
281  HTTP-date  = <HTTP-date, defined in [Part1], Section 6.1>
282]]></artwork></figure>
283<figure><artwork type="abnf2616"><![CDATA[
284  entity-tag = <entity-tag, defined in [Part4], Section 2>
285]]></artwork></figure>
286</section>
287
288</section>
289
290</section>
291
292
293<section title="Range Units" anchor="range.units">
294 
295 
296 
297<t>
298   HTTP/1.1 allows a client to request that only part (a range of) the
299   representation be included within the response. HTTP/1.1 uses range
300   units in the Range (<xref target="header.range"/>) and Content-Range (<xref target="header.content-range"/>)
301   header fields. A representation can be broken down into subranges according
302   to various structural units.
303</t>
304<figure><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"/><artwork type="abnf2616"><![CDATA[
305  range-unit       = bytes-unit / other-range-unit
306  bytes-unit       = "bytes"
307  other-range-unit = token
308]]></artwork></figure>
309<t>
310  HTTP/1.1 has been designed to allow implementations of applications
311  that do not depend on knowledge of ranges. The only range unit defined
312  by HTTP/1.1 is "bytes". Additional specifiers can be defined as described
313  in <xref target="range.specifier.registry"/>.
314</t>
315<t>
316  If a range unit is not understood in a request, a server MUST ignore
317  the whole Range header (<xref target="header.range"/>).
318  If a range unit is not understood in a response, an intermediary
319  SHOULD pass the response to the client; a client MUST fail.
320</t>
321
322<section title="Range Specifier Registry" anchor="range.specifier.registry">
323<t>
324   The HTTP Ranger Specifier Registry defines the name space for the range
325   specifier names.
326</t>
327<t>
328   Registrations MUST include the following fields:
329   <list style="symbols">
330     <t>Name</t>
331     <t>Description</t>
332     <t>Pointer to specification text</t>
333   </list>
334</t>
335<t>
336  Values to be added to this name space are subject to IETF review
337  (<xref target="RFC5226"/>, Section 4.1).
338</t>
339<t>
340   The registry itself is maintained at
341   <eref target="http://www.iana.org/assignments/http-range-specifiers"/>.
342</t>
343</section>
344
345</section>
346
347<section title="Status Code Definitions" anchor="status.code.definitions">
348<section title="206 Partial Content" anchor="status.206">
349  <iref primary="true" item="206 Partial Content (status code)"/>
350  <iref primary="true" item="Status Codes" subitem="206 Partial Content"/>
351<t>
352   The server has fulfilled the partial GET request for the resource.
353   The request MUST have included a Range header field (<xref target="header.range"/>)
354   indicating the desired range, and MAY have included an If-Range
355   header field (<xref target="header.if-range"/>) to make the request conditional.
356</t>
357<t>
358   The response MUST include the following header fields:
359  <list style="symbols">
360    <t>
361        Either a Content-Range header field (<xref target="header.content-range"/>) indicating
362        the range included with this response, or a multipart/byteranges
363        Content-Type including Content-Range fields for each part. If a
364        Content-Length header field is present in the response, its
365        value MUST match the actual number of octets transmitted in the
366        message-body.
367    </t>
368    <t>
369        Date
370    </t>
371    <t>
372        Cache-Control, ETag, Expires, Content-Location, Last-Modified,
373        and/or Vary, if the header field would have been sent in a 200
374        response to the same request
375    </t>
376  </list>
377</t>
378<t>
379   If the 206 response is the result of an If-Range request, the response
380   SHOULD NOT include other representation header fields. Otherwise, the response
381   MUST include all of the representation header fields that would have been returned
382   with a 200 (OK) response to the same request.
383</t>
384<t>
385   A cache MUST NOT combine a 206 response with other previously cached
386   content if the ETag or Last-Modified headers do not match exactly,
387   see <xref target="combining.byte.ranges"/>.
388</t>
389<t>
390   A cache that does not support the Range and Content-Range headers
391   MUST NOT cache 206 (Partial Content) responses. Furthermore,
392   if a response uses a range unit that is not understood by the cache,
393   then it MUST NOT be cached either.
394</t>
395</section>
396
397<section title="416 Requested Range Not Satisfiable" anchor="status.416">
398  <iref primary="true" item="416 Requested Range Not Satisfiable (status code)"/>
399  <iref primary="true" item="Status Codes" subitem="416 Requested Range Not Satisfiable"/>
400<t>
401   A server SHOULD return a response with this status code if a request
402   included a Range request-header field (<xref target="header.range"/>), and none of
403   the ranges-specifier values in this field overlap the current extent
404   of the selected resource, and the request did not include an If-Range
405   request-header field (<xref target="header.if-range"/>). (For byte-ranges,
406   this means that the first-byte-pos of all of the byte-range-spec values were
407   greater than the current length of the selected resource.)
408</t>
409<t>
410   When this status code is returned for a byte-range request, the
411   response SHOULD include a Content-Range header field
412   specifying the current length of the representation (see <xref target="header.content-range"/>).
413   This response MUST NOT use the multipart/byteranges content-type.
414</t>
415</section>
416</section>
417
418<section title="Combining Ranges" anchor="combining.byte.ranges">
419<t>
420   A response might transfer only a subrange of a representation, either because
421   the request included one or more Range specifications, or because
422   a connection closed prematurely.
423   After several such transfers, a cache might have received several
424   ranges of the same representation.
425</t>
426<t>
427   If a cache has a stored non-empty set of subranges for a representation, and
428   an incoming response transfers another subrange, the cache MAY
429   combine the new subrange with the existing set if both the following
430   conditions are met:
431  <list style="symbols">
432    <t>Both the incoming response and the cache entry have a cache
433        validator.</t>
434    <t>The two cache validators match using the strong comparison
435        function (see Section 4 of <xref target="Part4"/>).</t>
436  </list>
437</t>
438<t>
439   If either requirement is not met, the cache MUST use only the most
440   recent partial response (based on the Date values transmitted with
441   every response, and using the incoming response if these values are
442   equal or missing), and MUST discard the other partial information.
443</t>
444</section>
445
446<section title="Header Field Definitions" anchor="header.fields">
447<t>
448   This section defines the syntax and semantics of HTTP/1.1 header fields
449   related to range requests and partial responses.
450</t>
451
452<section title="Accept-Ranges" anchor="header.accept-ranges">
453  <iref primary="true" item="Accept-Ranges header"/>
454  <iref primary="true" item="Headers" subitem="Accept-Ranges"/>
455 
456 
457 
458<t>
459   The "Accept-Ranges" response-header field allows a resource to indicate
460   its acceptance of range requests.
461</t>
462<figure><iref primary="true" item="Grammar" subitem="Accept-Ranges"/><iref primary="true" item="Grammar" subitem="Accept-Ranges-v"/><iref primary="true" item="Grammar" subitem="acceptable-ranges"/><artwork type="abnf2616"><![CDATA[
463  Accept-Ranges     = "Accept-Ranges" ":" OWS Accept-Ranges-v
464  Accept-Ranges-v   = acceptable-ranges
465  acceptable-ranges = 1#range-unit / "none"
466]]></artwork></figure>
467<t>
468      Origin servers that accept byte-range requests MAY send
469</t>
470<figure><artwork type="example"><![CDATA[
471  Accept-Ranges: bytes
472]]></artwork></figure>
473<t>
474      but are not required to do so. Clients MAY generate range
475      requests without having received this header for the resource
476      involved. Range units are defined in <xref target="range.units"/>.
477</t>
478<t>
479      Servers that do not accept any kind of range request for a
480      resource MAY send
481</t>
482<figure><artwork type="example"><![CDATA[
483  Accept-Ranges: none
484]]></artwork></figure>
485<t>
486      to advise the client not to attempt a range request.
487</t>
488</section>
489
490<section title="Content-Range" anchor="header.content-range">
491  <iref primary="true" item="Content-Range header"/>
492  <iref primary="true" item="Headers" subitem="Content-Range"/>
493 
494 
495 
496 
497 
498 
499 
500 
501<t>
502   The "Content-Range" header field is sent with a partial representation to
503   specify where in the full representation the payload body is intended to be
504   applied.
505</t>
506<t>   
507   Range units are defined in <xref target="range.units"/>.
508</t>
509<figure><iref primary="true" item="Grammar" subitem="Content-Range"/><iref primary="true" item="Grammar" subitem="Content-Range-v"/><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"/><artwork type="abnf2616"><![CDATA[
510  Content-Range = "Content-Range" ":" OWS Content-Range-v
511  Content-Range-v = content-range-spec
512 
513  content-range-spec      = byte-content-range-spec
514                          / other-content-range-spec
515  byte-content-range-spec = bytes-unit SP
516                            byte-range-resp-spec "/"
517                            ( instance-length / "*" )
518 
519  byte-range-resp-spec    = (first-byte-pos "-" last-byte-pos)
520                          / "*"
521                         
522  instance-length         = 1*DIGIT
523 
524  other-content-range-spec = other-range-unit SP
525                             other-range-resp-spec
526  other-range-resp-spec    = *CHAR
527]]></artwork></figure>
528<t>
529   The header SHOULD indicate the total length of the full representation,
530   unless this length is unknown or difficult to determine. The asterisk
531   "*" character means that the instance-length is unknown at the time
532   when the response was generated.
533</t>
534<t>
535   Unlike byte-ranges-specifier values (see <xref target="byte.ranges"/>), a byte-range-resp-spec
536   MUST only specify one range, and MUST contain
537   absolute byte positions for both the first and last byte of the
538   range.
539</t>
540<t>
541   A byte-content-range-spec with a byte-range-resp-spec whose last-byte-pos
542   value is less than its first-byte-pos value, or whose
543   instance-length value is less than or equal to its last-byte-pos
544   value, is invalid. The recipient of an invalid byte-content-range-spec
545   MUST ignore it and any content transferred along with it.
546</t>
547<t>
548   In the case of a byte range request:
549   A server sending a response with status code 416 (Requested range not
550   satisfiable) SHOULD include a Content-Range field with a byte-range-resp-spec
551   of "*". The instance-length specifies the current length of
552   the selected resource. A response with status code 206 (Partial
553   Content) MUST NOT include a Content-Range field with a byte-range-resp-spec of "*".
554</t>
555<t>
556   Examples of byte-content-range-spec values, assuming that the representation
557   contains a total of 1234 bytes:
558   <list style="symbols">
559      <t>
560        The first 500 bytes:
561<figure><artwork type="example"><![CDATA[
562     bytes 0-499/1234
563   ]]></artwork></figure>
564      </t>   
565      <t>
566        The second 500 bytes:
567<figure><artwork type="example"><![CDATA[
568     bytes 500-999/1234
569   ]]></artwork></figure>
570      </t>   
571      <t>
572        All except for the first 500 bytes:
573<figure><artwork type="example"><![CDATA[
574     bytes 500-1233/1234
575   ]]></artwork></figure>
576      </t>   
577      <t>
578        The last 500 bytes:
579<figure><artwork type="example"><![CDATA[
580     bytes 734-1233/1234
581   ]]></artwork></figure>
582      </t>   
583   </list>
584</t>
585<t>
586   When an HTTP message includes the content of a single range (for
587   example, a response to a request for a single range, or to a request
588   for a set of ranges that overlap without any holes), this content is
589   transmitted with a Content-Range header, and a Content-Length header
590   showing the number of bytes actually transferred. For example,
591</t>
592<figure><artwork type="example"><![CDATA[
593  HTTP/1.1 206 Partial Content
594  Date: Wed, 15 Nov 1995 06:25:24 GMT
595  Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
596  Content-Range: bytes 21010-47021/47022
597  Content-Length: 26012
598  Content-Type: image/gif
599]]></artwork></figure>
600<t>
601   When an HTTP message includes the content of multiple ranges (for
602   example, a response to a request for multiple non-overlapping
603   ranges), these are transmitted as a multipart message. The multipart
604   media type used for this purpose is "multipart/byteranges" as defined
605   in <xref target="internet.media.type.multipart.byteranges"/>.
606</t>
607<t>
608   A response to a request for a single range MUST NOT be sent using the
609   multipart/byteranges media type.  A response to a request for
610   multiple ranges, whose result is a single range, MAY be sent as a
611   multipart/byteranges media type with one part. A client that cannot
612   decode a multipart/byteranges message MUST NOT ask for multiple
613   ranges in a single request.
614</t>
615<t>
616   When a client requests multiple ranges in one request, the
617   server SHOULD return them in the order that they appeared in the
618   request.
619</t>
620<t>
621   If the server ignores a byte-range-spec because it is syntactically
622   invalid, the server SHOULD treat the request as if the invalid Range
623   header field did not exist. (Normally, this means return a 200
624   response containing the full representation).
625</t>
626<t>
627   If the server receives a request (other than one including an If-Range
628   request-header field) with an unsatisfiable Range request-header
629   field (that is, all of whose byte-range-spec values have a
630   first-byte-pos value greater than the current length of the selected
631   resource), it SHOULD return a response code of 416 (Requested range
632   not satisfiable) (<xref target="status.416"/>).
633</t>
634<t><list>
635  <t>
636    Note: Clients cannot depend on servers to send a 416 (Requested
637    range not satisfiable) response instead of a 200 (OK) response for
638    an unsatisfiable Range request-header, since not all servers
639    implement this request-header.
640  </t>
641</list></t>
642</section>
643
644<section title="If-Range" anchor="header.if-range">
645  <iref primary="true" item="If-Range header"/>
646  <iref primary="true" item="Headers" subitem="If-Range"/>
647 
648 
649<t>
650   If a client has a partial copy of a representation in its cache, and wishes
651   to have an up-to-date copy of the entire representation in its cache, it
652   could use the Range request-header with a conditional GET (using
653   either or both of If-Unmodified-Since and If-Match.) However, if the
654   condition fails because the representation has been modified, the client
655   would then have to make a second request to obtain the entire current
656   representation.
657</t>
658<t>
659   The "If-Range" request-header field allows a client to "short-circuit" the second
660   request. Informally, its meaning is "if the representation is unchanged, send
661   me the part(s) that I am missing; otherwise, send me the entire new
662   representation".
663</t>
664<figure><iref primary="true" item="Grammar" subitem="If-Range"/><iref primary="true" item="Grammar" subitem="If-Range-v"/><artwork type="abnf2616"><![CDATA[
665  If-Range   = "If-Range" ":" OWS If-Range-v
666  If-Range-v = entity-tag / HTTP-date
667]]></artwork></figure>
668<t>
669   If the client has no entity-tag for a representation, but does have a Last-Modified
670   date, it MAY use that date in an If-Range header. (The
671   server can distinguish between a valid HTTP-date and any form of
672   entity-tag by examining no more than two characters.) The If-Range
673   header SHOULD only be used together with a Range header, and MUST be
674   ignored if the request does not include a Range header, or if the
675   server does not support the sub-range operation.
676</t>
677<t>
678   If the entity-tag given in the If-Range header matches the current
679   cache validator for the representation, then the server SHOULD provide the
680   specified sub-range of the representation using a 206 (Partial Content)
681   response. If the cache validator does not match, then the server SHOULD
682   return the entire representation using a 200 (OK) response.
683</t>
684</section>
685
686<section title="Range" anchor="header.range">
687  <iref primary="true" item="Range header"/>
688  <iref primary="true" item="Headers" subitem="Range"/>
689
690<section title="Byte Ranges" anchor="byte.ranges">
691<t>
692   Since all HTTP representations are transferred as sequences
693   of bytes, the concept of a byte range is meaningful for any HTTP
694   representation. (However, not all clients and servers need to support byte-range
695   operations.)
696</t>
697<t>
698   Byte range specifications in HTTP apply to the sequence of bytes in
699   the representation body (not necessarily the same as the message-body).
700</t>
701<t anchor="rule.ranges-specifier">
702 
703 
704 
705 
706 
707 
708 
709 
710
711   A byte range operation MAY specify a single range of bytes, or a set
712   of ranges within a single representation.
713</t>
714<figure><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"/><artwork type="abnf2616"><![CDATA[
715  byte-ranges-specifier = bytes-unit "=" byte-range-set
716  byte-range-set  = 1#( byte-range-spec / suffix-byte-range-spec )
717  byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
718  first-byte-pos  = 1*DIGIT
719  last-byte-pos   = 1*DIGIT
720]]></artwork></figure>
721<t>
722   The first-byte-pos value in a byte-range-spec gives the byte-offset
723   of the first byte in a range. The last-byte-pos value gives the
724   byte-offset of the last byte in the range; that is, the byte
725   positions specified are inclusive. Byte offsets start at zero.
726</t>
727<t>
728   If the last-byte-pos value is present, it MUST be greater than or
729   equal to the first-byte-pos in that byte-range-spec, or the byte-range-spec
730   is syntactically invalid. The recipient of a byte-range-set
731   that includes one or more syntactically invalid byte-range-spec
732   values MUST ignore the header field that includes that byte-range-set.
733</t>
734<t>
735   If the last-byte-pos value is absent, or if the value is greater than
736   or equal to the current length of the representation body, last-byte-pos is
737   taken to be equal to one less than the current length of the representation
738   in bytes.
739</t>
740<t>
741   By its choice of last-byte-pos, a client can limit the number of
742   bytes retrieved without knowing the size of the representation.
743</t>
744<figure><iref primary="true" item="Grammar" subitem="suffix-byte-range-spec"/><iref primary="true" item="Grammar" subitem="suffix-length"/><artwork type="abnf2616"><![CDATA[
745  suffix-byte-range-spec = "-" suffix-length
746  suffix-length = 1*DIGIT
747]]></artwork></figure>
748<t>
749   A suffix-byte-range-spec is used to specify the suffix of the
750   representation body, of a length given by the suffix-length value. (That is,
751   this form specifies the last N bytes of a representation.) If the
752   representation is shorter than the specified suffix-length, the entire
753   representation is used.
754</t>
755<t>
756   If a syntactically valid byte-range-set includes at least one byte-range-spec
757   whose first-byte-pos is less than the current length of
758   the representation, or at least one suffix-byte-range-spec with a non-zero
759   suffix-length, then the byte-range-set is satisfiable.
760   Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set
761   is unsatisfiable, the server SHOULD return a response with a
762   416 (Requested range not satisfiable) status code. Otherwise, the server
763   SHOULD return a response with a 206 (Partial Content) status code
764   containing the satisfiable ranges of the representation.
765</t>
766<t>
767   Examples of byte-ranges-specifier values (assuming a representation of
768   length 10000):
769  <list style="symbols">
770     <t>The first 500 bytes (byte offsets 0-499, inclusive):
771<figure><artwork type="example"><![CDATA[
772     bytes=0-499
773   ]]></artwork></figure>
774    </t>
775     <t>The second 500 bytes (byte offsets 500-999, inclusive):
776<figure><artwork type="example"><![CDATA[
777     bytes=500-999
778   ]]></artwork></figure>
779    </t>
780     <t>The final 500 bytes (byte offsets 9500-9999, inclusive):
781<figure><artwork type="example"><![CDATA[
782     bytes=-500
783   ]]></artwork></figure>
784    Or:
785<figure><artwork type="example"><![CDATA[
786     bytes=9500-
787   ]]></artwork></figure>
788    </t>
789     <t>The first and last bytes only (bytes 0 and 9999):
790<figure><artwork type="example"><![CDATA[
791     bytes=0-0,-1
792   ]]></artwork></figure>
793     </t>
794     <t>Several legal but not canonical specifications of the second 500
795        bytes (byte offsets 500-999, inclusive):
796<figure><artwork type="example"><![CDATA[
797     bytes=500-600,601-999
798     bytes=500-700,601-999
799   ]]></artwork></figure>
800     </t>
801  </list>
802</t>
803</section>
804
805<section title="Range Retrieval Requests" anchor="range.retrieval.requests">
806 
807 
808 
809 
810<t>
811   The "Range" request-header field defines the GET method (conditional or
812   not) to request one or more sub-ranges of the response representation body, instead
813   of the entire representation body.
814</t>
815<figure><iref primary="true" item="Grammar" subitem="Range"/><artwork type="abnf2616"><![CDATA[
816  Range   = "Range" ":" OWS Range-v
817  Range-v = byte-ranges-specifier
818          / other-ranges-specifier
819  other-ranges-specifier = other-range-unit "=" other-range-set
820  other-range-set = 1*CHAR
821]]></artwork></figure>
822<t>
823   A server MAY ignore the Range header. However, HTTP/1.1 origin
824   servers and intermediate caches ought to support byte ranges when
825   possible, since Range supports efficient recovery from partially
826   failed transfers, and supports efficient partial retrieval of large
827   representations.
828</t>
829<t>
830   If the server supports the Range header and the specified range or
831   ranges are appropriate for the representation:
832  <list style="symbols">
833     <t>The presence of a Range header in an unconditional GET modifies
834        what is returned if the GET is otherwise successful. In other
835        words, the response carries a status code of 206 (Partial
836        Content) instead of 200 (OK).</t>
837
838     <t>The presence of a Range header in a conditional GET (a request
839        using one or both of If-Modified-Since and If-None-Match, or
840        one or both of If-Unmodified-Since and If-Match) modifies what
841        is returned if the GET is otherwise successful and the
842        condition is true. It does not affect the 304 (Not Modified)
843        response returned if the conditional is false.</t>
844  </list>
845</t>
846<t>
847   In some cases, it might be more appropriate to use the If-Range
848   header (see <xref target="header.if-range"/>) in addition to the Range header.
849</t>
850<t>
851   If a proxy that supports ranges receives a Range request, forwards
852   the request to an inbound server, and receives an entire representation in
853   reply, it SHOULD only return the requested range to its client. It
854   SHOULD store the entire received response in its cache if that is
855   consistent with its cache allocation policies.
856</t>
857</section>
858</section>
859</section>
860
861<section title="IANA Considerations" anchor="IANA.considerations">
862
863<section title="Status Code Registration" anchor="status.code.registration">
864<t>
865   The HTTP Status Code Registry located at <eref target="http://www.iana.org/assignments/http-status-codes"/>
866   shall be updated with the registrations below:
867</t>
868
869<!--AUTOGENERATED FROM extract-status-code-defs.xslt, do not edit manually-->
870<texttable align="left" suppress-title="true" anchor="iana.status.code.registration.table">
871   <ttcol>Value</ttcol>
872   <ttcol>Description</ttcol>
873   <ttcol>Reference</ttcol>
874   <c>206</c>
875   <c>Partial Content</c>
876   <c>
877      <xref target="status.206"/>
878   </c>
879   <c>416</c>
880   <c>Requested Range Not Satisfiable</c>
881   <c>
882      <xref target="status.416"/>
883   </c>
884</texttable>
885<!--(END)-->
886
887</section>
888
889<section title="Header Field Registration" anchor="header.field.registration">
890<t>
891   The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> shall be updated
892   with the permanent registrations below (see <xref target="RFC3864"/>):
893</t>
894
895<!--AUTOGENERATED FROM extract-header-defs.xslt, do not edit manually-->
896<texttable align="left" suppress-title="true" anchor="iana.header.registration.table">
897   <ttcol>Header Field Name</ttcol>
898   <ttcol>Protocol</ttcol>
899   <ttcol>Status</ttcol>
900   <ttcol>Reference</ttcol>
901
902   <c>Accept-Ranges</c>
903   <c>http</c>
904   <c>standard</c>
905   <c>
906      <xref target="header.accept-ranges"/>
907   </c>
908   <c>Content-Range</c>
909   <c>http</c>
910   <c>standard</c>
911   <c>
912      <xref target="header.content-range"/>
913   </c>
914   <c>If-Range</c>
915   <c>http</c>
916   <c>standard</c>
917   <c>
918      <xref target="header.if-range"/>
919   </c>
920   <c>Range</c>
921   <c>http</c>
922   <c>standard</c>
923   <c>
924      <xref target="header.range"/>
925   </c>
926</texttable>
927<!--(END)-->
928
929<t>
930   The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
931</t>
932</section>
933
934<section title="Range Specifier Registration" anchor="range.specifier.registration">
935<t>
936  The registration procedure for HTTP Range Specifiers is defined by
937  <xref target="range.specifier.registry"/> of this document.
938</t>
939<t>
940   The HTTP Range Specifier Registry shall be created at <eref target="http://www.iana.org/assignments/http-range-specifiers"/>
941   and be populated with the registrations below:
942</t>
943<texttable align="left" suppress-title="true" anchor="iana.range.specifiers.table">
944   <ttcol>Range Specifier Name</ttcol>
945   <ttcol>Description</ttcol>
946   <ttcol>Reference</ttcol>
947
948   <c>bytes</c>
949   <c>a range of octets</c>
950   <c>(this specification)</c>
951</texttable>
952<t>
953   The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
954</t>
955</section>
956</section>
957
958<section title="Security Considerations" anchor="security.considerations">
959<t>
960   No additional security considerations have been identified beyond
961   those applicable to HTTP in general <xref target="Part1"/>.
962</t>
963</section>
964
965<section title="Acknowledgments" anchor="ack">
966<t>
967   Most of the specification of ranges is based on work originally done
968   by Ari Luotonen and John Franks, with additional input from Steve
969   Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin Hamilton,
970   Koen Holtman, Shel Kaplan, Paul Leach, Alex Lopez-Ortiz, Larry Masinter,
971   Jeff Mogul, Lou Montulli, David W. Morris, Luigi Rizzo, and Bill Weihl.
972</t>
973</section>
974</middle>
975<back>
976
977<references title="Normative References">
978
979<reference anchor="Part1">
980  <front>
981    <title abbrev="HTTP/1.1">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</title>
982    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
983      <organization abbrev="Day Software">Day Software</organization>
984      <address><email>fielding@gbiv.com</email></address>
985    </author>
986    <author initials="J." surname="Gettys" fullname="Jim Gettys">
987      <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization>
988      <address><email>jg@freedesktop.org</email></address>
989    </author>
990    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
991      <organization abbrev="HP">Hewlett-Packard Company</organization>
992      <address><email>JeffMogul@acm.org</email></address>
993    </author>
994    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
995      <organization abbrev="Microsoft">Microsoft Corporation</organization>
996      <address><email>henrikn@microsoft.com</email></address>
997    </author>
998    <author initials="L." surname="Masinter" fullname="Larry Masinter">
999      <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
1000      <address><email>LMM@acm.org</email></address>
1001    </author>
1002    <author initials="P." surname="Leach" fullname="Paul J. Leach">
1003      <organization abbrev="Microsoft">Microsoft Corporation</organization>
1004      <address><email>paulle@microsoft.com</email></address>
1005    </author>
1006    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
1007      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
1008      <address><email>timbl@w3.org</email></address>
1009    </author>
1010    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
1011      <organization abbrev="W3C">World Wide Web Consortium</organization>
1012      <address><email>ylafon@w3.org</email></address>
1013    </author>
1014    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
1015      <organization abbrev="greenbytes">greenbytes GmbH</organization>
1016      <address><email>julian.reschke@greenbytes.de</email></address>
1017    </author>
1018    <date month="August" year="2010"/>
1019  </front>
1020  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-11"/>
1021 
1022</reference>
1023
1024<reference anchor="Part4">
1025  <front>
1026    <title abbrev="HTTP/1.1">HTTP/1.1, part 4: Conditional Requests</title>
1027    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
1028      <organization abbrev="Day Software">Day Software</organization>
1029      <address><email>fielding@gbiv.com</email></address>
1030    </author>
1031    <author initials="J." surname="Gettys" fullname="Jim Gettys">
1032      <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization>
1033      <address><email>jg@freedesktop.org</email></address>
1034    </author>
1035    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
1036      <organization abbrev="HP">Hewlett-Packard Company</organization>
1037      <address><email>JeffMogul@acm.org</email></address>
1038    </author>
1039    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
1040      <organization abbrev="Microsoft">Microsoft Corporation</organization>
1041      <address><email>henrikn@microsoft.com</email></address>
1042    </author>
1043    <author initials="L." surname="Masinter" fullname="Larry Masinter">
1044      <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
1045      <address><email>LMM@acm.org</email></address>
1046    </author>
1047    <author initials="P." surname="Leach" fullname="Paul J. Leach">
1048      <organization abbrev="Microsoft">Microsoft Corporation</organization>
1049      <address><email>paulle@microsoft.com</email></address>
1050    </author>
1051    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
1052      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
1053      <address><email>timbl@w3.org</email></address>
1054    </author>
1055    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
1056      <organization abbrev="W3C">World Wide Web Consortium</organization>
1057      <address><email>ylafon@w3.org</email></address>
1058    </author>
1059    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
1060      <organization abbrev="greenbytes">greenbytes GmbH</organization>
1061      <address><email>julian.reschke@greenbytes.de</email></address>
1062    </author>
1063    <date month="August" year="2010"/>
1064  </front>
1065  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p4-conditional-11"/>
1066 
1067</reference>
1068
1069<reference anchor="RFC2046">
1070  <front>
1071    <title abbrev="Media Types">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</title>
1072    <author initials="N." surname="Freed" fullname="Ned Freed">
1073      <organization>Innosoft International, Inc.</organization>
1074      <address><email>ned@innosoft.com</email></address>
1075    </author>
1076    <author initials="N." surname="Borenstein" fullname="Nathaniel S. Borenstein">
1077      <organization>First Virtual Holdings</organization>
1078      <address><email>nsb@nsb.fv.com</email></address>
1079    </author>
1080    <date month="November" year="1996"/>
1081  </front>
1082  <seriesInfo name="RFC" value="2046"/>
1083</reference>
1084
1085<reference anchor="RFC2119">
1086  <front>
1087    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
1088    <author initials="S." surname="Bradner" fullname="Scott Bradner">
1089      <organization>Harvard University</organization>
1090      <address><email>sob@harvard.edu</email></address>
1091    </author>
1092    <date month="March" year="1997"/>
1093  </front>
1094  <seriesInfo name="BCP" value="14"/>
1095  <seriesInfo name="RFC" value="2119"/>
1096</reference>
1097
1098<reference anchor="RFC5234">
1099  <front>
1100    <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title>
1101    <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor">
1102      <organization>Brandenburg InternetWorking</organization>
1103      <address>
1104        <email>dcrocker@bbiw.net</email>
1105      </address> 
1106    </author>
1107    <author initials="P." surname="Overell" fullname="Paul Overell">
1108      <organization>THUS plc.</organization>
1109      <address>
1110        <email>paul.overell@thus.net</email>
1111      </address>
1112    </author>
1113    <date month="January" year="2008"/>
1114  </front>
1115  <seriesInfo name="STD" value="68"/>
1116  <seriesInfo name="RFC" value="5234"/>
1117</reference>
1118
1119</references>
1120
1121<references title="Informative References">
1122
1123<reference anchor="RFC2616">
1124  <front>
1125    <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
1126    <author initials="R." surname="Fielding" fullname="R. Fielding">
1127      <organization>University of California, Irvine</organization>
1128      <address><email>fielding@ics.uci.edu</email></address>
1129    </author>
1130    <author initials="J." surname="Gettys" fullname="J. Gettys">
1131      <organization>W3C</organization>
1132      <address><email>jg@w3.org</email></address>
1133    </author>
1134    <author initials="J." surname="Mogul" fullname="J. Mogul">
1135      <organization>Compaq Computer Corporation</organization>
1136      <address><email>mogul@wrl.dec.com</email></address>
1137    </author>
1138    <author initials="H." surname="Frystyk" fullname="H. Frystyk">
1139      <organization>MIT Laboratory for Computer Science</organization>
1140      <address><email>frystyk@w3.org</email></address>
1141    </author>
1142    <author initials="L." surname="Masinter" fullname="L. Masinter">
1143      <organization>Xerox Corporation</organization>
1144      <address><email>masinter@parc.xerox.com</email></address>
1145    </author>
1146    <author initials="P." surname="Leach" fullname="P. Leach">
1147      <organization>Microsoft Corporation</organization>
1148      <address><email>paulle@microsoft.com</email></address>
1149    </author>
1150    <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
1151      <organization>W3C</organization>
1152      <address><email>timbl@w3.org</email></address>
1153    </author>
1154    <date month="June" year="1999"/>
1155  </front>
1156  <seriesInfo name="RFC" value="2616"/>
1157</reference>
1158
1159<reference anchor="RFC3864">
1160  <front>
1161    <title>Registration Procedures for Message Header Fields</title>
1162    <author initials="G." surname="Klyne" fullname="G. Klyne">
1163      <organization>Nine by Nine</organization>
1164      <address><email>GK-IETF@ninebynine.org</email></address>
1165    </author>
1166    <author initials="M." surname="Nottingham" fullname="M. Nottingham">
1167      <organization>BEA Systems</organization>
1168      <address><email>mnot@pobox.com</email></address>
1169    </author>
1170    <author initials="J." surname="Mogul" fullname="J. Mogul">
1171      <organization>HP Labs</organization>
1172      <address><email>JeffMogul@acm.org</email></address>
1173    </author>
1174    <date year="2004" month="September"/>
1175  </front>
1176  <seriesInfo name="BCP" value="90"/>
1177  <seriesInfo name="RFC" value="3864"/>
1178</reference>
1179
1180<reference anchor="RFC4288">
1181  <front>
1182    <title>Media Type Specifications and Registration Procedures</title>
1183    <author initials="N." surname="Freed" fullname="N. Freed">
1184      <organization>Sun Microsystems</organization>
1185      <address>
1186        <email>ned.freed@mrochek.com</email>
1187      </address>
1188    </author>
1189    <author initials="J." surname="Klensin" fullname="J. Klensin">
1190      <address>
1191        <email>klensin+ietf@jck.com</email>
1192      </address>
1193    </author>
1194    <date year="2005" month="December"/>
1195  </front>
1196  <seriesInfo name="BCP" value="13"/>
1197  <seriesInfo name="RFC" value="4288"/>
1198</reference>
1199
1200<reference anchor="RFC5226">
1201  <front>
1202    <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
1203    <author initials="T." surname="Narten" fullname="T. Narten">
1204      <organization>IBM</organization>
1205      <address><email>narten@us.ibm.com</email></address>
1206    </author>
1207    <author initials="H." surname="Alvestrand" fullname="H. Alvestrand">
1208      <organization>Google</organization>
1209      <address><email>Harald@Alvestrand.no</email></address>
1210    </author>
1211    <date year="2008" month="May"/>
1212  </front>
1213  <seriesInfo name="BCP" value="26"/>
1214  <seriesInfo name="RFC" value="5226"/>
1215</reference>
1216
1217</references>
1218
1219<section title="Internet Media Type multipart/byteranges" anchor="internet.media.type.multipart.byteranges">
1220<iref item="Media Type" subitem="multipart/byteranges" primary="true"/>
1221<iref item="multipart/byteranges Media Type" primary="true"/>
1222<t>
1223   When an HTTP 206 (Partial Content) response message includes the
1224   content of multiple ranges (a response to a request for multiple
1225   non-overlapping ranges), these are transmitted as a multipart
1226   message-body (<xref target="RFC2046"/>, Section 5.1). The media type for this purpose is called
1227   "multipart/byteranges".  The following is to be registered with IANA <xref target="RFC4288"/>.
1228</t>
1229<t><list>
1230  <t>
1231    Note: Despite the name "multipart/byteranges" is not limited to the byte ranges only.
1232  </t>
1233</list></t>
1234<t>
1235   The multipart/byteranges media type includes one or more parts, each
1236   with its own Content-Type and Content-Range fields. The required
1237   boundary parameter specifies the boundary string used to separate
1238   each body-part.
1239</t>
1240<t>
1241  <list style="hanging">
1242    <t hangText="Type name:">
1243      multipart
1244    </t>
1245    <t hangText="Subtype name:">
1246      byteranges
1247    </t>
1248    <t hangText="Required parameters:">
1249      boundary
1250    </t>
1251    <t hangText="Optional parameters:">
1252      none
1253    </t>
1254    <t hangText="Encoding considerations:">
1255      only "7bit", "8bit", or "binary" are permitted
1256    </t>
1257    <t hangText="Security considerations:">
1258      none
1259    </t>
1260    <t hangText="Interoperability considerations:">
1261      none
1262    </t>
1263    <t hangText="Published specification:">
1264      This specification (see <xref target="internet.media.type.multipart.byteranges"/>).
1265    </t>
1266    <t hangText="Applications that use this media type:">
1267    </t>
1268    <t hangText="Additional information:">
1269      <list style="hanging">
1270        <t hangText="Magic number(s):">none</t>
1271        <t hangText="File extension(s):">none</t>
1272        <t hangText="Macintosh file type code(s):">none</t>
1273      </list>
1274    </t>
1275    <t hangText="Person and email address to contact for further information:">
1276      See Authors Section.
1277    </t>
1278    <t hangText="Intended usage:">
1279      COMMON
1280    </t>
1281    <t hangText="Restrictions on usage:">
1282      none
1283    </t>
1284    <t hangText="Author/Change controller:">
1285      IESG
1286    </t>
1287  </list>
1288</t>
1289<figure><preamble>
1290   For example:
1291</preamble><artwork type="example"><![CDATA[
1292  HTTP/1.1 206 Partial Content
1293  Date: Wed, 15 Nov 1995 06:25:24 GMT
1294  Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
1295  Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
1296 
1297  --THIS_STRING_SEPARATES
1298  Content-type: application/pdf
1299  Content-range: bytes 500-999/8000
1300 
1301  ...the first range...
1302  --THIS_STRING_SEPARATES
1303  Content-type: application/pdf
1304  Content-range: bytes 7000-7999/8000
1305 
1306  ...the second range
1307  --THIS_STRING_SEPARATES--
1308]]></artwork></figure>
1309<figure><preamble>
1310   Other example:
1311</preamble>
1312<artwork type="example"><![CDATA[
1313  HTTP/1.1 206 Partial Content
1314  Date: Tue, 14 Nov 1995 06:25:24 GMT
1315  Last-Modified: Tue, 14 July 04:58:08 GMT
1316  Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
1317 
1318  --THIS_STRING_SEPARATES
1319  Content-type: video/example
1320  Content-range: exampleunit 1.2-4.3/25
1321 
1322  ...the first range...
1323  --THIS_STRING_SEPARATES
1324  Content-type: video/example
1325  Content-range: exampleunit 11.2-14.3/25
1326 
1327  ...the second range
1328  --THIS_STRING_SEPARATES--
1329]]></artwork>
1330</figure>
1331<t>
1332      Notes:
1333  <list style="numbers">
1334      <t>Additional CRLFs MAY precede the first boundary string in the body.</t>
1335
1336      <t>Although <xref target="RFC2046"/> permits the boundary string to be
1337         quoted, some existing implementations handle a quoted boundary
1338         string incorrectly.</t>
1339
1340      <t>A number of browsers and servers were coded to an early draft
1341         of the byteranges specification to use a media type of
1342         multipart/x-byteranges<iref item="multipart/x-byteranges Media Type"/><iref item="Media Type" subitem="multipart/x-byteranges"/>, which is almost, but not quite
1343         compatible with the version documented in HTTP/1.1.</t>
1344  </list>
1345</t>
1346</section>
1347
1348<section title="Compatibility with Previous Versions" anchor="compatibility">
1349<section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">
1350<t>
1351  Clarify that it is not ok to use a weak cache validator in a 206 response.
1352  (<xref target="status.206"/>)
1353</t>
1354<t>
1355  Clarify that multipart/byteranges can consist of a single part.
1356  (<xref target="internet.media.type.multipart.byteranges"/>)
1357</t>
1358
1359</section>
1360
1361</section>
1362
1363
1364<section title="Collected ABNF" anchor="collected.abnf">
1365<figure>
1366<artwork type="abnf" name="p5-range.parsed-abnf"><![CDATA[
1367Accept-Ranges = "Accept-Ranges:" OWS Accept-Ranges-v
1368Accept-Ranges-v = acceptable-ranges
1369
1370Content-Range = "Content-Range:" OWS Content-Range-v
1371Content-Range-v = content-range-spec
1372
1373HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
1374
1375If-Range = "If-Range:" OWS If-Range-v
1376If-Range-v = entity-tag / HTTP-date
1377
1378OWS = <OWS, defined in [Part1], Section 1.2.2>
1379
1380Range = "Range:" OWS Range-v
1381Range-v = byte-ranges-specifier / other-ranges-specifier
1382
1383acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS
1384 range-unit ] ) ) / "none"
1385
1386byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" (
1387 instance-length / "*" )
1388byte-range-resp-spec = ( first-byte-pos "-" last-byte-pos ) / "*"
1389byte-range-set = ( *( "," OWS ) byte-range-spec ) / (
1390 suffix-byte-range-spec *( OWS "," [ ( OWS byte-range-spec ) /
1391 suffix-byte-range-spec ] ) )
1392byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
1393byte-ranges-specifier = bytes-unit "=" byte-range-set
1394bytes-unit = "bytes"
1395
1396content-range-spec = byte-content-range-spec /
1397 other-content-range-spec
1398
1399entity-tag = <entity-tag, defined in [Part4], Section 2>
1400
1401first-byte-pos = 1*DIGIT
1402
1403instance-length = 1*DIGIT
1404
1405last-byte-pos = 1*DIGIT
1406
1407other-content-range-spec = other-range-unit SP other-range-resp-spec
1408other-range-resp-spec = *CHAR
1409other-range-set = 1*CHAR
1410other-range-unit = token
1411other-ranges-specifier = other-range-unit "=" other-range-set
1412
1413range-unit = bytes-unit / other-range-unit
1414
1415suffix-byte-range-spec = "-" suffix-length
1416suffix-length = 1*DIGIT
1417
1418token = <token, defined in [Part1], Section 1.2.2>
1419]]></artwork>
1420</figure>
1421<figure><preamble>ABNF diagnostics:</preamble><artwork type="inline"><![CDATA[
1422; Accept-Ranges defined but not used
1423; Content-Range defined but not used
1424; If-Range defined but not used
1425; Range defined but not used
1426]]></artwork></figure></section>
1427
1428
1429
1430<section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log">
1431
1432<section title="Since RFC2616">
1433<t>
1434  Extracted relevant partitions from <xref target="RFC2616"/>.
1435</t>
1436</section>
1437
1438<section title="Since draft-ietf-httpbis-p5-range-00">
1439<t>
1440  Closed issues:
1441  <list style="symbols"> 
1442    <t>
1443      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/18"/>:
1444      "Cache validators in 206 responses"
1445      (<eref target="http://purl.org/NET/http-errata#ifrange206"/>)
1446    </t>
1447    <t>
1448      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/35"/>:
1449      "Normative and Informative references"
1450    </t>
1451    <t>
1452      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/86"/>:
1453      "Normative up-to-date references"
1454    </t>
1455  </list>
1456</t>
1457</section>
1458
1459<section title="Since draft-ietf-httpbis-p5-range-01">
1460<t>
1461  Closed issues:
1462  <list style="symbols"> 
1463    <t>
1464      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/55"/>:
1465      "Updating to RFC4288"
1466    </t>
1467  </list>
1468</t>
1469<t>
1470  Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>):
1471  <list style="symbols"> 
1472    <t>
1473      Add explicit references to BNF syntax and rules imported from other parts of the specification.
1474    </t>
1475  </list>
1476</t>
1477</section>
1478
1479<section title="Since draft-ietf-httpbis-p5-range-02" anchor="changes.since.02">
1480<t>
1481  Ongoing work on IANA Message Header Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>):
1482  <list style="symbols"> 
1483    <t>
1484      Reference RFC 3984, and update header registrations for headers defined
1485      in this document.
1486    </t>
1487  </list>
1488</t>
1489</section>
1490
1491<section title="Since draft-ietf-httpbis-p5-range-03" anchor="changes.since.03">
1492<t>
1493</t>
1494</section>
1495
1496<section title="Since draft-ietf-httpbis-p5-range-04" anchor="changes.since.04">
1497<t>
1498  Closed issues:
1499  <list style="symbols"> 
1500    <t>
1501      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/133"/>:
1502      "multipart/byteranges minimum number of parts"
1503    </t>
1504  </list>
1505</t>
1506<t>
1507  Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>):
1508  <list style="symbols"> 
1509    <t>
1510      Use "/" instead of "|" for alternatives.
1511    </t>
1512    <t>
1513      Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
1514      whitespace ("OWS") and required whitespace ("RWS").
1515    </t>
1516    <t>
1517      Rewrite ABNFs to spell out whitespace rules, factor out
1518      header value format definitions.
1519    </t>
1520  </list>
1521</t>
1522</section>
1523
1524<section title="Since draft-ietf-httpbis-p5-range-05" anchor="changes.since.05">
1525<t>
1526  Closed issues:
1527  <list style="symbols"> 
1528    <t>
1529      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/142"/>:
1530      "State base for *-byte-pos and suffix-length"
1531    </t>
1532  </list>
1533</t>
1534<t>
1535  Ongoing work on Custom Ranges (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/85"/>):
1536  <list style="symbols"> 
1537    <t>
1538      Remove bias in favor of byte ranges; allow custom ranges in ABNF.
1539    </t>
1540  </list>
1541</t>
1542<t>
1543  Final work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>):
1544  <list style="symbols"> 
1545    <t>
1546      Add appendix containing collected and expanded ABNF, reorganize ABNF introduction.
1547    </t>
1548  </list>
1549</t>
1550</section>
1551
1552<section title="Since draft-ietf-httpbis-p5-range-06" anchor="changes.since.06">
1553<t>
1554  Closed issues:
1555  <list style="symbols"> 
1556    <t>
1557      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/161"/>:
1558      "base for numeric protocol elements"
1559    </t>
1560  </list>
1561</t>
1562</section>
1563
1564<section title="Since draft-ietf-httpbis-p5-range-07" anchor="changes.since.07">
1565<t>
1566  Closed issues:
1567  <list style="symbols">
1568    <t>
1569      Fixed discrepancy in the If-Range definition about allowed validators.
1570    </t>
1571    <t>
1572      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/150"/>: "multipart/byteranges for custom range units"
1573    </t>
1574    <t>
1575      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/151"/>: "range unit missing from other-ranges-specifier in Range header"
1576    </t>
1577    <t>
1578      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/198"/>:
1579      "move IANA registrations for optional status codes"
1580    </t>
1581  </list>
1582</t>
1583</section>
1584
1585<section title="Since draft-ietf-httpbis-p5-range-08" anchor="changes.since.08">
1586<t>
1587  No significant changes.
1588</t>
1589</section>
1590
1591<section title="Since draft-ietf-httpbis-p5-range-09" anchor="changes.since.09">
1592<t>
1593 No significant changes.
1594</t>
1595</section>
1596
1597<section title="Since draft-ietf-httpbis-p5-range-10" anchor="changes.since.10">
1598<t>
1599  Closed issues:
1600  <list style="symbols"> 
1601    <t>
1602      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/69"/>:
1603      "Clarify 'Requested Variant'"
1604    </t>
1605    <t>
1606      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/109"/>:
1607      "Clarify entity / representation / variant terminology"
1608    </t>
1609    <t>
1610      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>:
1611      "consider removing the 'changes from 2068' sections"
1612    </t>
1613  </list>
1614</t>
1615<t>
1616  Ongoing work on Custom Ranges (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/85"/>):
1617  <list style="symbols"> 
1618    <t>
1619      Add IANA registry.
1620    </t>
1621  </list>
1622</t>
1623</section>
1624
1625</section>
1626
1627</back>
1628</rfc>
Note: See TracBrowser for help on using the repository browser.