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

Last change on this file since 2531 was 2531, checked in by fielding@…, 7 years ago

slightly rephrase [2525]; see #542

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