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

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

make RFC5234 citations consistent

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