source: draft-ietf-httpbis/23/draft-ietf-httpbis-p5-range-23.xml @ 2568

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

prepare release of -23

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