source: draft-ietf-httpbis/25/draft-ietf-httpbis-p5-range-25.xml @ 2656

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

prepare publication of -25 drafts on 2013-11-17

  • Property svn:mime-type set to text/xml
File size: 58.0 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-25">
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="November" year="2013" day="17"/>
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.24"/>.
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 7 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 MUST 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   An origin server that supports byte-range requests for a given target
317   resource MAY send
318</t>
319<figure><artwork type="example"><![CDATA[
320  Accept-Ranges: bytes
321]]></artwork></figure>
322<t>
323   to indicate what range units are supported. A client MAY generate range
324   requests without having received this header field for the resource
325   involved. Range units are defined in <xref target="range.units"/>.
326</t>
327<t>
328   A server that does not support any kind of range request for the target
329   resource MAY send
330</t>
331<figure><artwork type="example"><![CDATA[
332  Accept-Ranges: none
333]]></artwork></figure>
334<t>
335   to advise the client not to attempt a range request.
336</t>
337</section>
338</section>
339
340
341<section title="Range Requests" anchor="range.requests">
342<section title="Range" anchor="header.range">
343  <iref primary="true" item="Range header field"/>
344 
345 
346 
347<t>
348   The "Range" header field on a GET request modifies the method semantics to
349   request transfer of only one or more subranges of the selected
350   representation data, rather than the entire selected representation data.
351</t>
352<figure><iref primary="true" item="Grammar" subitem="Range"/><artwork type="abnf2616"><![CDATA[
353  Range = byte-ranges-specifier / other-ranges-specifier
354  other-ranges-specifier = other-range-unit "=" other-range-set
355  other-range-set = 1*CHAR
356]]></artwork></figure>
357<t>
358   A server MAY ignore the Range header field. However, origin servers and
359   intermediate caches ought to support byte ranges when possible, since Range
360   supports efficient recovery from partially failed transfers and partial
361   retrieval of large representations. A server MUST ignore a Range header
362   field received with a request method other than GET.
363</t>
364<t>
365   An origin server MUST ignore a Range header field that contains a range
366   unit it does not understand. A proxy MAY discard a Range header
367   field that contains a range unit it does not understand.
368</t>
369<t>
370   A server that supports range requests MAY 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 precondition 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 in a request that
439   does not contain a <xref target="header.range" format="none">Range</xref> header field.
440   A server MUST ignore an If-Range header field received in a request that
441   does not contain a <xref target="header.range" format="none">Range</xref> header field.
442   An origin server MUST ignore an If-Range header field received in a
443   request for a target resource that does not support Range requests.
444</t>
445<t>
446   A client MUST NOT generate an If-Range header field containing an
447   entity-tag that is marked as weak.
448   A client MUST NOT generate an If-Range header field containing an
449   <xref target="imported.abnf" format="none">HTTP-date</xref> unless the client has no entity-tag for
450   the corresponding representation and the date is a strong validator
451   in the sense defined by Section 2.2.2 of <xref target="Part4"/>.
452</t>
453<t>
454   A server that evaluates an If-Range precondition MUST use the strong
455   comparison function when comparing entity-tags (Section 2.3.2 of <xref target="Part4"/>)
456   and MUST evaluate the condition as false if an <xref target="imported.abnf" format="none">HTTP-date</xref>
457   validator is provided that is not a strong validator in the sense defined
458   by Section 2.2.2 of <xref target="Part4"/>.
459   (A server can distinguish between a valid <xref target="imported.abnf" format="none">HTTP-date</xref> and any
460   form of entity-tag by examining the first two characters.)
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 <xref target="header.range" format="none">Range</xref> header field as
466   requested. If the validator does not match, 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 section 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 by default; i.e., unless otherwise indicated by
591   explicit cache controls (see Section 4.2.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   (Section 2.1 of <xref target="Part4"/>).
724</t>
725<t>
726   A client that has received multiple partial responses to GET requests on a
727   target resource MAY combine those responses into a larger continuous
728   range if they share the same strong validator.
729</t>
730<t>
731   If the most recent response is an incomplete 200 (OK)
732   response, then the header fields of that response are used for any
733   combined response and replace those of the matching stored responses.
734</t>
735<t>
736   If the most recent response is a <xref target="status.206" format="none">206 (Partial Content)</xref>
737   response and at least one of the matching stored responses is a
738   200 (OK), then the combined response header fields consist
739   of the most recent 200 response's header fields. If all of the matching
740   stored responses are 206 responses, then the stored response with the most
741   recent header fields is used as the source of header fields for the
742   combined response, except that the client MUST use other header fields
743   provided in the new response, aside from <xref target="header.content-range" format="none">Content-Range</xref>, to
744   replace all instances of the corresponding header fields in the stored
745   response.
746</t>
747<t>
748   The combined response message body consists of the union of partial
749   content ranges in the new response and each of the selected responses.
750   If the union consists of the entire range of the representation, then the
751   client MUST process the combined response as if it were a complete
752   200 (OK) response, including a Content-Length
753   header field that reflects the complete length.
754   Otherwise, the client MUST process the set of continuous ranges as one of
755   the following:
756   an incomplete 200 (OK) response if the combined response is
757   a prefix of the representation,
758   a single <xref target="status.206" format="none">206 (Partial Content)</xref> response containing a
759   multipart/byteranges body, or
760   multiple <xref target="status.206" format="none">206 (Partial Content)</xref> responses, each with one
761   continuous range that is indicated by a <xref target="header.content-range" format="none">Content-Range</xref> header
762   field.
763</t>
764</section>
765
766<section title="416 Range Not Satisfiable" anchor="status.416">
767  <iref primary="true" item="416 Range Not Satisfiable (status code)"/>
768 
769<t>
770   The 416 (Range Not Satisfiable) status code indicates that
771   none of the ranges in the request's <xref target="header.range" format="none">Range</xref> header field
772   (<xref target="header.range"/>) overlap the current extent of the selected
773   resource or that the set of ranges requested has been rejected due to
774   invalid ranges or an excessive request of small or overlapping ranges.
775</t>
776<t>
777   For byte ranges, failing to overlap the current extent means that the
778   <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>
779   values were greater than the current length of the selected representation.
780   When this status code is generated in response to a byte range request, the
781   sender SHOULD generate a <xref target="header.content-range" format="none">Content-Range</xref> header field
782   specifying the current length of the selected representation
783   (<xref target="header.content-range"/>).
784</t>
785<figure>
786<preamble>For example:</preamble>
787<artwork type="message/http; msgtype=&#34;response&#34;"><![CDATA[
788  HTTP/1.1 416 Range Not Satisfiable
789  Date: Fri, 20 Jan 2012 15:41:54 GMT
790  Content-Range: bytes */47022
791  ]]></artwork></figure>
792<t><list>
793  <t>
794    Note: Because servers are free to ignore <xref target="header.range" format="none">Range</xref>, many
795    implementations will simply respond with the entire selected representation
796    in a 200 (OK) response. That is partly because
797    most clients are prepared to receive a 200 (OK) to
798    complete the task (albeit less efficiently) and partly because clients
799    might not stop making an invalid partial request until they have received
800    a complete representation. Thus, clients cannot depend on receiving a
801    <xref target="status.416" format="none">416 (Range Not Satisfiable)</xref> response even when it is most
802    appropriate.
803  </t>
804</list></t>
805</section>
806</section>
807
808<section title="IANA Considerations" anchor="IANA.considerations">
809
810<section title="Range Unit Registry" anchor="range.unit.registry">
811<t>
812   The HTTP Range Unit Registry defines the name space for the range
813   unit names and refers to their corresponding specifications.
814   The registry will be created and maintained at (the suggested URI)
815   <eref target="http://www.iana.org/assignments/http-parameters"/>.
816</t>
817
818<section title="Procedure" anchor="range.unit.registry.procedure">
819<t>
820   Registration of an HTTP Range Unit MUST include the following fields:
821   <list style="symbols">
822     <t>Name</t>
823     <t>Description</t>
824     <t>Pointer to specification text</t>
825   </list>
826</t>
827<t>
828  Values to be added to this name space require IETF Review
829  (see <xref target="RFC5226"/>, Section 4.1).
830</t>
831</section>
832
833<section title="Registrations" anchor="range.unit.registration">
834<t>
835   The initial HTTP Range Unit Registry shall contain the registrations
836   below:
837</t>
838<texttable align="left" suppress-title="true" anchor="iana.range.units.table">
839   <ttcol>Range Unit Name</ttcol>
840   <ttcol>Description</ttcol>
841   <ttcol>Reference</ttcol>
842
843   <c>bytes</c>
844   <c>a range of octets</c>
845   <c><xref target="byte.ranges"/></c>
846
847   <c>none</c>
848   <c>reserved as keyword, indicating no ranges are supported</c>
849   <c><xref target="header.accept-ranges"/></c>
850</texttable>
851<t>
852   The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
853</t>
854</section>
855</section>
856
857<section title="Status Code Registration" anchor="status.code.registration">
858<t>
859   The HTTP Status Code Registry located at <eref target="http://www.iana.org/assignments/http-status-codes"/>
860   shall be updated with the registrations below:
861</t>
862
863<!--AUTOGENERATED FROM extract-status-code-defs.xslt, do not edit manually-->
864<texttable align="left" suppress-title="true" anchor="iana.status.code.registration.table">
865   <ttcol>Value</ttcol>
866   <ttcol>Description</ttcol>
867   <ttcol>Reference</ttcol>
868   <c>206</c>
869   <c>Partial Content</c>
870   <c>
871      <xref target="status.206"/>
872   </c>
873   <c>416</c>
874   <c>Range Not Satisfiable</c>
875   <c>
876      <xref target="status.416"/>
877   </c>
878</texttable>
879<!--(END)-->
880
881</section>
882
883<section title="Header Field Registration" anchor="header.field.registration">
884<t>
885   HTTP header fields are registered within the Message Header Field Registry
886   maintained at
887   <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/>.
888</t>
889<t>
890   This document defines the following HTTP header fields, so their
891   associated registry entries shall be updated according to the permanent
892   registrations below (see <xref target="BCP90"/>):
893</t>
894
895<!--AUTOGENERATED FROM extract-header-defs.xslt, do not edit manually-->
896<texttable align="left" suppress-title="true" anchor="iana.header.registration.table">
897   <ttcol>Header Field Name</ttcol>
898   <ttcol>Protocol</ttcol>
899   <ttcol>Status</ttcol>
900   <ttcol>Reference</ttcol>
901
902   <c>Accept-Ranges</c>
903   <c>http</c>
904   <c>standard</c>
905   <c>
906      <xref target="header.accept-ranges"/>
907   </c>
908   <c>Content-Range</c>
909   <c>http</c>
910   <c>standard</c>
911   <c>
912      <xref target="header.content-range"/>
913   </c>
914   <c>If-Range</c>
915   <c>http</c>
916   <c>standard</c>
917   <c>
918      <xref target="header.if-range"/>
919   </c>
920   <c>Range</c>
921   <c>http</c>
922   <c>standard</c>
923   <c>
924      <xref target="header.range"/>
925   </c>
926</texttable>
927<!--(END)-->
928
929<t>
930   The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
931</t>
932</section>
933
934<section title="Internet Media Type Registration" anchor="internet.media.type.http">
935<t>
936   IANA maintains the registry of Internet media types <xref target="BCP13"/> at
937   <eref target="http://www.iana.org/assignments/media-types"/>.
938</t>
939<t>
940   This document serves as the specification for the Internet media type
941   "multipart/byteranges". The following is to be registered with
942   IANA.
943</t>
944<section title="Internet Media Type multipart/byteranges" anchor="internet.media.type.multipart.byteranges.reg">
945<iref item="Media Type" subitem="multipart/byteranges" primary="true"/>
946<iref item="multipart/byteranges Media Type" primary="true"/>
947<t>
948  <list style="hanging">
949    <t hangText="Type name:">
950      multipart
951    </t>
952    <t hangText="Subtype name:">
953      byteranges
954    </t>
955    <t hangText="Required parameters:">
956      boundary
957    </t>
958    <t hangText="Optional parameters:">
959      none
960    </t>
961    <t hangText="Encoding considerations:">
962      only "7bit", "8bit", or "binary" are permitted
963    </t>
964    <t hangText="Security considerations:">
965      none
966    </t>
967    <t hangText="Interoperability considerations:">
968      none
969    </t>
970    <t hangText="Published specification:">
971      This specification (see <xref target="internet.media.type.multipart.byteranges"/>).
972    </t>
973    <t hangText="Applications that use this media type:">
974      HTTP components supporting multiple ranges in a single request.
975    </t>
976    <t hangText="Additional information:">
977      <list style="hanging">
978        <t hangText="Magic number(s):">none</t>
979        <t hangText="File extension(s):">none</t>
980        <t hangText="Macintosh file type code(s):">none</t>
981      </list>
982    </t>
983    <t hangText="Person and email address to contact for further information:">
984      See Authors Section.
985    </t>
986    <t hangText="Intended usage:">
987      COMMON
988    </t>
989    <t hangText="Restrictions on usage:">
990      none
991    </t>
992    <t hangText="Author:">
993      See Authors Section.
994    </t>
995    <t hangText="Change controller:">
996      IESG
997    </t>
998  </list>
999</t>
1000</section>
1001</section>
1002
1003</section>
1004
1005<section title="Security Considerations" anchor="security.considerations">
1006<t>
1007   This section is meant to inform developers, information providers, and
1008   users of known security concerns specific to the HTTP/1.1 range
1009   request mechanisms. More general security considerations are addressed
1010   in HTTP messaging <xref target="Part1"/> and semantics <xref target="Part2"/>.
1011</t>
1012
1013<section title="Denial of Service Attacks using Range" anchor="overlapping.ranges">
1014<t>
1015   Unconstrained multiple range requests are susceptible to denial of service
1016   attacks because the effort required to request many overlapping ranges of
1017   the same data is tiny compared to the time, memory, and bandwidth consumed
1018   by attempting to serve the requested data in many parts.
1019   Servers ought to ignore, coalesce, or reject egregious range requests, such
1020   as requests for more than two overlapping ranges or for many small ranges
1021   in a single set, particularly when the ranges are requested out of order
1022   for no apparent reason. Multipart range requests are not designed to
1023   support random access.
1024</t>
1025</section>
1026</section>
1027
1028<section title="Acknowledgments" anchor="acks">
1029<t>
1030  See Section 10 of <xref target="Part1"/>.
1031</t>
1032</section>
1033</middle>
1034<back>
1035
1036<references title="Normative References">
1037
1038<reference anchor="Part1">
1039  <front>
1040    <title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
1041    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
1042      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
1043      <address><email>fielding@gbiv.com</email></address>
1044    </author>
1045    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
1046      <organization abbrev="greenbytes">greenbytes GmbH</organization>
1047      <address><email>julian.reschke@greenbytes.de</email></address>
1048    </author>
1049    <date month="November" year="2013"/>
1050  </front>
1051  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-25"/>
1052 
1053</reference>
1054
1055<reference anchor="Part2">
1056  <front>
1057    <title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
1058    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
1059      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
1060      <address><email>fielding@gbiv.com</email></address>
1061    </author>
1062    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
1063      <organization abbrev="greenbytes">greenbytes GmbH</organization>
1064      <address><email>julian.reschke@greenbytes.de</email></address>
1065    </author>
1066    <date month="November" year="2013"/>
1067  </front>
1068  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-25"/>
1069 
1070</reference>
1071
1072<reference anchor="Part4">
1073  <front>
1074    <title>Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</title>
1075    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
1076      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
1077      <address><email>fielding@gbiv.com</email></address>
1078    </author>
1079    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
1080      <organization abbrev="greenbytes">greenbytes GmbH</organization>
1081      <address><email>julian.reschke@greenbytes.de</email></address>
1082    </author>
1083    <date month="November" year="2013"/>
1084  </front>
1085  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p4-conditional-25"/>
1086 
1087</reference>
1088
1089<reference anchor="Part6">
1090  <front>
1091    <title>Hypertext Transfer Protocol (HTTP/1.1): Caching</title>
1092    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
1093      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
1094      <address><email>fielding@gbiv.com</email></address>
1095    </author>
1096    <author initials="M." surname="Nottingham" fullname="Mark Nottingham" role="editor">
1097      <organization>Akamai</organization>
1098      <address><email>mnot@mnot.net</email></address>
1099    </author>
1100    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
1101      <organization abbrev="greenbytes">greenbytes GmbH</organization>
1102      <address><email>julian.reschke@greenbytes.de</email></address>
1103    </author>
1104    <date month="November" year="2013"/>
1105  </front>
1106  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-25"/>
1107 
1108</reference>
1109
1110<reference anchor="RFC2046">
1111  <front>
1112    <title abbrev="Media Types">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</title>
1113    <author initials="N." surname="Freed" fullname="Ned Freed">
1114      <organization>Innosoft International, Inc.</organization>
1115      <address><email>ned@innosoft.com</email></address>
1116    </author>
1117    <author initials="N." surname="Borenstein" fullname="Nathaniel S. Borenstein">
1118      <organization>First Virtual Holdings</organization>
1119      <address><email>nsb@nsb.fv.com</email></address>
1120    </author>
1121    <date month="November" year="1996"/>
1122  </front>
1123  <seriesInfo name="RFC" value="2046"/>
1124</reference>
1125
1126<reference anchor="RFC2119">
1127  <front>
1128    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
1129    <author initials="S." surname="Bradner" fullname="Scott Bradner">
1130      <organization>Harvard University</organization>
1131      <address><email>sob@harvard.edu</email></address>
1132    </author>
1133    <date month="March" year="1997"/>
1134  </front>
1135  <seriesInfo name="BCP" value="14"/>
1136  <seriesInfo name="RFC" value="2119"/>
1137</reference>
1138
1139<reference anchor="RFC5234">
1140  <front>
1141    <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title>
1142    <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor">
1143      <organization>Brandenburg InternetWorking</organization>
1144      <address>
1145        <email>dcrocker@bbiw.net</email>
1146      </address> 
1147    </author>
1148    <author initials="P." surname="Overell" fullname="Paul Overell">
1149      <organization>THUS plc.</organization>
1150      <address>
1151        <email>paul.overell@thus.net</email>
1152      </address>
1153    </author>
1154    <date month="January" year="2008"/>
1155  </front>
1156  <seriesInfo name="STD" value="68"/>
1157  <seriesInfo name="RFC" value="5234"/>
1158</reference>
1159
1160</references>
1161
1162<references title="Informative References">
1163
1164<reference anchor="RFC2616">
1165  <front>
1166    <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
1167    <author initials="R." surname="Fielding" fullname="R. Fielding">
1168      <organization>University of California, Irvine</organization>
1169      <address><email>fielding@ics.uci.edu</email></address>
1170    </author>
1171    <author initials="J." surname="Gettys" fullname="J. Gettys">
1172      <organization>W3C</organization>
1173      <address><email>jg@w3.org</email></address>
1174    </author>
1175    <author initials="J." surname="Mogul" fullname="J. Mogul">
1176      <organization>Compaq Computer Corporation</organization>
1177      <address><email>mogul@wrl.dec.com</email></address>
1178    </author>
1179    <author initials="H." surname="Frystyk" fullname="H. Frystyk">
1180      <organization>MIT Laboratory for Computer Science</organization>
1181      <address><email>frystyk@w3.org</email></address>
1182    </author>
1183    <author initials="L." surname="Masinter" fullname="L. Masinter">
1184      <organization>Xerox Corporation</organization>
1185      <address><email>masinter@parc.xerox.com</email></address>
1186    </author>
1187    <author initials="P." surname="Leach" fullname="P. Leach">
1188      <organization>Microsoft Corporation</organization>
1189      <address><email>paulle@microsoft.com</email></address>
1190    </author>
1191    <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
1192      <organization>W3C</organization>
1193      <address><email>timbl@w3.org</email></address>
1194    </author>
1195    <date month="June" year="1999"/>
1196  </front>
1197  <seriesInfo name="RFC" value="2616"/>
1198</reference>
1199
1200<reference anchor="BCP90">
1201  <front>
1202    <title>Registration Procedures for Message Header Fields</title>
1203    <author initials="G." surname="Klyne" fullname="G. Klyne">
1204      <organization>Nine by Nine</organization>
1205      <address><email>GK-IETF@ninebynine.org</email></address>
1206    </author>
1207    <author initials="M." surname="Nottingham" fullname="M. Nottingham">
1208      <organization>BEA Systems</organization>
1209      <address><email>mnot@pobox.com</email></address>
1210    </author>
1211    <author initials="J." surname="Mogul" fullname="J. Mogul">
1212      <organization>HP Labs</organization>
1213      <address><email>JeffMogul@acm.org</email></address>
1214    </author>
1215    <date year="2004" month="September"/>
1216  </front>
1217  <seriesInfo name="BCP" value="90"/>
1218  <seriesInfo name="RFC" value="3864"/>
1219</reference>
1220
1221<reference anchor="BCP13">
1222  <front>
1223    <title>Media Type Specifications and Registration Procedures</title>
1224    <author initials="N." surname="Freed" fullname="Ned Freed">
1225      <organization>Oracle</organization>
1226      <address>
1227        <email>ned+ietf@mrochek.com</email>
1228      </address>
1229    </author>
1230    <author initials="J." surname="Klensin" fullname="John C. Klensin">
1231      <address>
1232        <email>john+ietf@jck.com</email>
1233      </address>
1234    </author>
1235    <author initials="T." surname="Hansen" fullname="Tony Hansen">
1236      <organization>AT&amp;T Laboratories</organization>
1237      <address>
1238        <email>tony+mtsuffix@maillennium.att.com</email>
1239      </address>
1240    </author>
1241    <date year="2013" month="January"/>
1242  </front>
1243  <seriesInfo name="BCP" value="13"/>
1244  <seriesInfo name="RFC" value="6838"/>
1245</reference>
1246
1247<reference anchor="RFC5226">
1248  <front>
1249    <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
1250    <author initials="T." surname="Narten" fullname="T. Narten">
1251      <organization>IBM</organization>
1252      <address><email>narten@us.ibm.com</email></address>
1253    </author>
1254    <author initials="H." surname="Alvestrand" fullname="H. Alvestrand">
1255      <organization>Google</organization>
1256      <address><email>Harald@Alvestrand.no</email></address>
1257    </author>
1258    <date year="2008" month="May"/>
1259  </front>
1260  <seriesInfo name="BCP" value="26"/>
1261  <seriesInfo name="RFC" value="5226"/>
1262</reference>
1263
1264</references>
1265
1266<section title="Internet Media Type multipart/byteranges" anchor="internet.media.type.multipart.byteranges">
1267<iref item="Media Type" subitem="multipart/byteranges" primary="true"/>
1268<iref item="multipart/byteranges Media Type" primary="true"/>
1269<t>
1270   When a <xref target="status.206" format="none">206 (Partial Content)</xref> response message includes the
1271   content of multiple ranges, they are transmitted as body parts in a
1272   multipart message body (<xref target="RFC2046"/>, Section 5.1)
1273   with the media type of "multipart/byteranges".
1274</t>
1275<t>
1276   The multipart/byteranges media type includes one or more body parts, each
1277   with its own Content-Type and <xref target="header.content-range" format="none">Content-Range</xref>
1278   fields. The required boundary parameter specifies the boundary string used
1279   to separate each body part.
1280</t>
1281<t>
1282  Implementation Notes:
1283  <list style="numbers">
1284      <t>Additional CRLFs might precede the first boundary string in the body.</t>
1285
1286      <t>Although <xref target="RFC2046"/> permits the boundary string to be
1287         quoted, some existing implementations handle a quoted boundary
1288         string incorrectly.</t>
1289
1290      <t>A number of clients and servers were coded to an early draft
1291         of the byteranges specification that used a media type of
1292         multipart/x-byteranges<iref item="multipart/x-byteranges Media Type"/><iref item="Media Type" subitem="multipart/x-byteranges"/>,
1293         which is almost (but not quite) compatible with this type.</t>
1294  </list>
1295</t>
1296<t>
1297   Despite the name, the "multipart/byteranges" media type is not limited to
1298   byte ranges. The following example uses an "exampleunit" range unit:
1299</t>
1300<figure><artwork type="message/http; msgtype=&#34;response&#34;"><![CDATA[
1301  HTTP/1.1 206 Partial Content
1302  Date: Tue, 14 Nov 1995 06:25:24 GMT
1303  Last-Modified: Tue, 14 July 04:58:08 GMT
1304  Content-Length: 2331785
1305  Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
1306 
1307  --THIS_STRING_SEPARATES
1308  Content-Type: video/example
1309  Content-Range: exampleunit 1.2-4.3/25
1310 
1311  ...the first range...
1312  --THIS_STRING_SEPARATES
1313  Content-Type: video/example
1314  Content-Range: exampleunit 11.2-14.3/25
1315 
1316  ...the second range
1317  --THIS_STRING_SEPARATES--
1318  ]]></artwork>
1319</figure>
1320</section>
1321
1322<section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">
1323<t>
1324  Servers are given more leeway in how they respond to a range request,
1325  in order to mitigate abuse by malicious (or just greedy) clients.
1326  (<xref target="header.range"/>)
1327</t>
1328<t>
1329  A weak validator cannot be used in a <xref target="status.206" format="none">206</xref> response.
1330  (<xref target="status.206"/>)
1331</t>
1332<t>
1333  The Content-Range header field only has meaning when the status code
1334  explicitly defines its use.
1335  (<xref target="header.content-range"/>)
1336</t>
1337<t>
1338  This specification introduces a Range Unit Registry.
1339  (<xref target="range.unit.registry"/>)
1340</t>
1341<t>
1342  multipart/byteranges can consist of a single part.
1343  (<xref target="internet.media.type.multipart.byteranges"/>)
1344</t>
1345</section>
1346
1347<section title="Imported ABNF" anchor="imported.abnf">
1348 
1349 
1350 
1351 
1352 
1353 
1354 
1355 
1356 
1357 
1358 
1359 
1360<t>
1361  The following core rules are included by
1362  reference, as defined in Appendix B.1 of <xref target="RFC5234"/>:
1363  ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls),
1364  DIGIT (decimal 0-9), DQUOTE (double quote),
1365  HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed),
1366  OCTET (any 8-bit sequence of data), SP (space), and
1367  VCHAR (any visible US-ASCII character).
1368</t>
1369<t>
1370  Note that all rules derived from <xref target="imported.abnf" format="none">token</xref> are to
1371  be compared case-insensitively, like <xref target="range.units" format="none">range-unit</xref> and
1372  <xref target="header.accept-ranges" format="none">acceptable-ranges</xref>.
1373</t>
1374<t>
1375  The rules below are defined in <xref target="Part1"/>:
1376</t>
1377<figure><artwork type="abnf2616"><![CDATA[
1378  OWS        = <OWS, defined in [Part1], Section 3.2.3>
1379  token      = <token, defined in [Part1], Section 3.2.6>
1380]]></artwork></figure>
1381<t>
1382  The rules below are defined in other parts:
1383</t>
1384<figure><artwork type="abnf2616"><![CDATA[
1385  HTTP-date  = <HTTP-date, defined in [Part2], Section 7.1.1.1>
1386  entity-tag = <entity-tag, defined in [Part4], Section 2.3>
1387]]></artwork></figure>
1388</section>
1389
1390
1391<section title="Collected ABNF" anchor="collected.abnf">
1392<t>
1393  In the collected ABNF below, list rules are expanded as per Section 1.2 of <xref target="Part1"/>.
1394</t><figure>
1395<artwork type="abnf" name="p5-range.parsed-abnf"><![CDATA[
1396Accept-Ranges = acceptable-ranges
1397
1398Content-Range = byte-content-range / other-content-range
1399
1400HTTP-date = <HTTP-date, defined in [Part2], Section 7.1.1.1>
1401
1402If-Range = entity-tag / HTTP-date
1403
1404OWS = <OWS, defined in [Part1], Section 3.2.3>
1405
1406Range = byte-ranges-specifier / other-ranges-specifier
1407
1408acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS
1409 range-unit ] ) ) / "none"
1410
1411byte-content-range = bytes-unit SP ( byte-range-resp /
1412 unsatisfied-range )
1413byte-range = first-byte-pos "-" last-byte-pos
1414byte-range-resp = byte-range "/" ( complete-length / "*" )
1415byte-range-set = *( "," OWS ) ( byte-range-spec /
1416 suffix-byte-range-spec ) *( OWS "," [ OWS ( byte-range-spec /
1417 suffix-byte-range-spec ) ] )
1418byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
1419byte-ranges-specifier = bytes-unit "=" byte-range-set
1420bytes-unit = "bytes"
1421
1422complete-length = 1*DIGIT
1423
1424entity-tag = <entity-tag, defined in [Part4], Section 2.3>
1425
1426first-byte-pos = 1*DIGIT
1427
1428last-byte-pos = 1*DIGIT
1429
1430other-content-range = other-range-unit SP other-range-resp
1431other-range-resp = *CHAR
1432other-range-set = 1*CHAR
1433other-range-unit = token
1434other-ranges-specifier = other-range-unit "=" other-range-set
1435
1436range-unit = bytes-unit / other-range-unit
1437
1438suffix-byte-range-spec = "-" suffix-length
1439suffix-length = 1*DIGIT
1440
1441token = <token, defined in [Part1], Section 3.2.6>
1442
1443unsatisfied-range = "*/" complete-length
1444]]></artwork>
1445</figure>
1446</section>
1447
1448
1449
1450<section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log">
1451<t>
1452  Changes up to the IETF Last Call draft are summarized
1453  in <eref target="http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-24#appendix-E"/>.
1454</t>
1455
1456<section title="Since draft-ietf-httpbis-p5-range-24" anchor="changes.since.24">
1457<t>
1458  Closed issues:
1459  <list style="symbols">
1460    <t>
1461      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/506"/>:
1462      "APPSDIR review of draft-ietf-httpbis-p5-range-24"
1463    </t>
1464    <t>
1465      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/507"/>:
1466      "integer value parsing"
1467    </t>
1468    <t>
1469      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/508"/>:
1470      "broken sentence in description of 206"
1471    </t>
1472  </list>
1473</t>
1474</section>
1475</section>
1476
1477</back>
1478</rfc>
Note: See TracBrowser for help on using the repository browser.