source: draft-ietf-httpbis/latest/auth48/rfc7233-to-be.xml @ 2705

Last change on this file since 2705 was 2690, checked in by julian.reschke@…, 6 years ago

updated AUTH48 version of RFC7233 (#553)

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