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

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

fix references/affiliations

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