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

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

prepare publication of -26

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