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

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

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