source: draft-ietf-httpbis/22/draft-ietf-httpbis-p5-range-22.xml @ 2561

Last change on this file since 2561 was 2190, checked in by julian.reschke@…, 7 years ago

prepare -22 for release

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