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

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

(editorial) move range unit registry to IANA considerations like we did for p2 registries

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