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

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

(editorial) move Vary to p2 because it is generated by origin servers and not limited to caching

  • Property svn:eol-style set to native
  • Property svn:mime-type set to text/xml
File size: 61.0 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, 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. 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>HTTP/1.1, part 1: Message Routing and Syntax"</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>HTTP/1.1, part 2: Semantics and Payloads</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>HTTP/1.1, part 4: 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>HTTP/1.1, part 6: 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      <organization>Rackspace</organization>
1057      <address><email>mnot@mnot.net</email></address>
1058    </author>
1059    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
1060      <organization abbrev="greenbytes">greenbytes GmbH</organization>
1061      <address><email>julian.reschke@greenbytes.de</email></address>
1062    </author>
1063    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
1064  </front>
1065  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-&ID-VERSION;"/>
1066  <x:source href="p6-cache.xml" basename="p6-cache">
1067    <x:defines>Cache-Control</x:defines>
1068    <x:defines>Expires</x:defines>
1069  </x:source>
1070</reference>
1071
1072<reference anchor="RFC2046">
1073  <front>
1074    <title abbrev="Media Types">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</title>
1075    <author initials="N." surname="Freed" fullname="Ned Freed">
1076      <organization>Innosoft International, Inc.</organization>
1077      <address><email>ned@innosoft.com</email></address>
1078    </author>
1079    <author initials="N." surname="Borenstein" fullname="Nathaniel S. Borenstein">
1080      <organization>First Virtual Holdings</organization>
1081      <address><email>nsb@nsb.fv.com</email></address>
1082    </author>
1083    <date month="November" year="1996"/>
1084  </front>
1085  <seriesInfo name="RFC" value="2046"/>
1086</reference>
1087
1088<reference anchor="RFC2119">
1089  <front>
1090    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
1091    <author initials="S." surname="Bradner" fullname="Scott Bradner">
1092      <organization>Harvard University</organization>
1093      <address><email>sob@harvard.edu</email></address>
1094    </author>
1095    <date month="March" year="1997"/>
1096  </front>
1097  <seriesInfo name="BCP" value="14"/>
1098  <seriesInfo name="RFC" value="2119"/>
1099</reference>
1100
1101<reference anchor="RFC5234">
1102  <front>
1103    <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title>
1104    <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor">
1105      <organization>Brandenburg InternetWorking</organization>
1106      <address>
1107        <email>dcrocker@bbiw.net</email>
1108      </address> 
1109    </author>
1110    <author initials="P." surname="Overell" fullname="Paul Overell">
1111      <organization>THUS plc.</organization>
1112      <address>
1113        <email>paul.overell@thus.net</email>
1114      </address>
1115    </author>
1116    <date month="January" year="2008"/>
1117  </front>
1118  <seriesInfo name="STD" value="68"/>
1119  <seriesInfo name="RFC" value="5234"/>
1120</reference>
1121
1122</references>
1123
1124<references title="Informative References">
1125
1126<reference anchor="RFC2616">
1127  <front>
1128    <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
1129    <author initials="R." surname="Fielding" fullname="R. Fielding">
1130      <organization>University of California, Irvine</organization>
1131      <address><email>fielding@ics.uci.edu</email></address>
1132    </author>
1133    <author initials="J." surname="Gettys" fullname="J. Gettys">
1134      <organization>W3C</organization>
1135      <address><email>jg@w3.org</email></address>
1136    </author>
1137    <author initials="J." surname="Mogul" fullname="J. Mogul">
1138      <organization>Compaq Computer Corporation</organization>
1139      <address><email>mogul@wrl.dec.com</email></address>
1140    </author>
1141    <author initials="H." surname="Frystyk" fullname="H. Frystyk">
1142      <organization>MIT Laboratory for Computer Science</organization>
1143      <address><email>frystyk@w3.org</email></address>
1144    </author>
1145    <author initials="L." surname="Masinter" fullname="L. Masinter">
1146      <organization>Xerox Corporation</organization>
1147      <address><email>masinter@parc.xerox.com</email></address>
1148    </author>
1149    <author initials="P." surname="Leach" fullname="P. Leach">
1150      <organization>Microsoft Corporation</organization>
1151      <address><email>paulle@microsoft.com</email></address>
1152    </author>
1153    <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
1154      <organization>W3C</organization>
1155      <address><email>timbl@w3.org</email></address>
1156    </author>
1157    <date month="June" year="1999"/>
1158  </front>
1159  <seriesInfo name="RFC" value="2616"/>
1160</reference>
1161
1162<reference anchor='RFC3864'>
1163  <front>
1164    <title>Registration Procedures for Message Header Fields</title>
1165    <author initials='G.' surname='Klyne' fullname='G. Klyne'>
1166      <organization>Nine by Nine</organization>
1167      <address><email>GK-IETF@ninebynine.org</email></address>
1168    </author>
1169    <author initials='M.' surname='Nottingham' fullname='M. Nottingham'>
1170      <organization>BEA Systems</organization>
1171      <address><email>mnot@pobox.com</email></address>
1172    </author>
1173    <author initials='J.' surname='Mogul' fullname='J. Mogul'>
1174      <organization>HP Labs</organization>
1175      <address><email>JeffMogul@acm.org</email></address>
1176    </author>
1177    <date year='2004' month='September' />
1178  </front>
1179  <seriesInfo name='BCP' value='90' />
1180  <seriesInfo name='RFC' value='3864' />
1181</reference>
1182
1183<reference anchor="RFC4288">
1184  <front>
1185    <title>Media Type Specifications and Registration Procedures</title>
1186    <author initials="N." surname="Freed" fullname="N. Freed">
1187      <organization>Sun Microsystems</organization>
1188      <address>
1189        <email>ned.freed@mrochek.com</email>
1190      </address>
1191    </author>
1192    <author initials="J." surname="Klensin" fullname="J. Klensin">
1193      <address>
1194        <email>klensin+ietf@jck.com</email>
1195      </address>
1196    </author>
1197    <date year="2005" month="December"/>
1198  </front>
1199  <seriesInfo name="BCP" value="13"/>
1200  <seriesInfo name="RFC" value="4288"/>
1201</reference>
1202
1203<reference anchor='RFC5226'>
1204  <front>
1205    <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
1206    <author initials='T.' surname='Narten' fullname='T. Narten'>
1207      <organization>IBM</organization>
1208      <address><email>narten@us.ibm.com</email></address>
1209    </author>
1210    <author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'>
1211      <organization>Google</organization>
1212      <address><email>Harald@Alvestrand.no</email></address>
1213    </author>
1214    <date year='2008' month='May' />
1215  </front>
1216  <seriesInfo name='BCP' value='26' />
1217  <seriesInfo name='RFC' value='5226' />
1218</reference>
1219
1220</references>
1221
1222<section title="Internet Media Type multipart/byteranges" anchor="internet.media.type.multipart.byteranges">
1223<iref item="Media Type" subitem="multipart/byteranges" primary="true"/>
1224<iref item="multipart/byteranges Media Type" primary="true"/>
1225<t>
1226   When an HTTP <x:ref>206 (Partial Content)</x:ref> response message includes the
1227   content of multiple ranges (a response to a request for multiple
1228   non-overlapping ranges), these are transmitted as a multipart
1229   message body (<xref target="RFC2046" x:fmt="," x:sec="5.1"/>). The media type for this purpose is called
1230   "multipart/byteranges".  The following is to be registered with IANA <xref target="RFC4288"/>.
1231</t>
1232<t>
1233   The multipart/byteranges media type includes one or more parts, each
1234   with its own <x:ref>Content-Type</x:ref> and <x:ref>Content-Range</x:ref>
1235   fields. The required boundary parameter specifies the boundary string used
1236   to separate each body-part.
1237</t>
1238<t>
1239  <list style="hanging" x:indent="12em">
1240    <t hangText="Type name:">
1241      multipart
1242    </t>
1243    <t hangText="Subtype name:">
1244      byteranges
1245    </t>
1246    <t hangText="Required parameters:">
1247      boundary
1248    </t>
1249    <t hangText="Optional parameters:">
1250      none
1251    </t>
1252    <t hangText="Encoding considerations:">
1253      only "7bit", "8bit", or "binary" are permitted
1254    </t>
1255    <t hangText="Security considerations:">
1256      none
1257    </t>
1258    <t hangText="Interoperability considerations:">
1259      none
1260    </t>
1261    <t hangText="Published specification:">
1262      This specification (see <xref target="internet.media.type.multipart.byteranges"/>).
1263    </t>
1264    <t hangText="Applications that use this media type:">
1265      HTTP components supporting multiple ranges in a single request.
1266    </t>
1267    <t hangText="Additional information:">
1268      <list style="hanging">
1269        <t hangText="Magic number(s):">none</t>
1270        <t hangText="File extension(s):">none</t>
1271        <t hangText="Macintosh file type code(s):">none</t>
1272      </list>
1273    </t>
1274    <t hangText="Person and email address to contact for further information:">
1275      See Authors Section.
1276    </t>
1277    <t hangText="Intended usage:">
1278      COMMON
1279    </t>
1280    <t hangText="Restrictions on usage:">
1281      none
1282    </t>
1283    <t hangText="Author/Change controller:">
1284      IESG
1285    </t>
1286  </list>
1287</t>
1288<x:note>
1289  <t>
1290    &Note; Despite the name "multipart/byteranges" is not limited to the byte ranges only.
1291  </t>
1292</x:note>
1293<figure><preamble>
1294   For example:
1295</preamble><artwork type="example">
1296  HTTP/1.1 206 Partial Content
1297  Date: Wed, 15 Nov 1995 06:25:24 GMT
1298  Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
1299  Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
1300 
1301  --THIS_STRING_SEPARATES
1302  Content-type: application/pdf
1303  Content-range: bytes 500-999/8000
1304 
1305  ...the first range...
1306  --THIS_STRING_SEPARATES
1307  Content-type: application/pdf
1308  Content-range: bytes 7000-7999/8000
1309 
1310  ...the second range
1311  --THIS_STRING_SEPARATES--
1312</artwork></figure>
1313<figure><preamble>
1314   Another example, using the "exampleunit" range unit:
1315</preamble>
1316<artwork type="example">
1317  HTTP/1.1 206 Partial Content
1318  Date: Tue, 14 Nov 1995 06:25:24 GMT
1319  Last-Modified: Tue, 14 July 04:58:08 GMT
1320  Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
1321 
1322  --THIS_STRING_SEPARATES
1323  Content-type: video/example
1324  Content-range: exampleunit 1.2-4.3/25
1325 
1326  ...the first range...
1327  --THIS_STRING_SEPARATES
1328  Content-type: video/example
1329  Content-range: exampleunit 11.2-14.3/25
1330 
1331  ...the second range
1332  --THIS_STRING_SEPARATES--
1333</artwork>
1334</figure>
1335<t>
1336  Notes:
1337  <list style="numbers">
1338      <t>Additional CRLFs &MAY; precede the first boundary string in the body.</t>
1339
1340      <t>Although <xref target="RFC2046"/> permits the boundary string to be
1341         quoted, some existing implementations handle a quoted boundary
1342         string incorrectly.</t>
1343
1344      <t>A number of clients and servers were coded to an early draft
1345         of the byteranges specification to use a media type of
1346         multipart/x-byteranges<iref item="multipart/x-byteranges Media Type"/><iref item="Media Type" subitem="multipart/x-byteranges"/>, which is almost, but not quite
1347         compatible with the version documented in HTTP/1.1.</t>
1348  </list>
1349</t>
1350</section>
1351
1352<section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">
1353<t>
1354  Introduce Range Specifier Registry.
1355  (<xref target="range.specifier.registry"/>)
1356</t>
1357<t>
1358  Clarify that it is not ok to use a weak validator in a <x:ref>206</x:ref> response.
1359  (<xref target="status.206"/>)
1360</t>
1361<t>
1362  Change ABNF productions for header fields to only define the field value.
1363  (<xref target="header.field.definitions"/>)
1364</t>
1365<t>
1366  Clarify that multipart/byteranges can consist of a single part.
1367  (<xref target="internet.media.type.multipart.byteranges"/>)
1368</t>
1369</section>
1370
1371<section title="Imported ABNF" anchor="imported.abnf">
1372  <x:anchor-alias value="ALPHA"/>
1373  <x:anchor-alias value="CHAR"/>
1374  <x:anchor-alias value="CR"/>
1375  <x:anchor-alias value="DIGIT"/>
1376  <x:anchor-alias value="LF"/>
1377  <x:anchor-alias value="OCTET"/>
1378  <x:anchor-alias value="SP"/>
1379  <x:anchor-alias value="VCHAR"/>
1380  <x:anchor-alias value="token"/>
1381  <x:anchor-alias value="OWS"/>
1382  <x:anchor-alias value="HTTP-date"/>
1383  <x:anchor-alias value="entity-tag"/>
1384<t>
1385  The following core rules are included by
1386  reference, as defined in <xref target="RFC5234" x:fmt="of" x:sec="B.1"/>:
1387  ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls),
1388  DIGIT (decimal 0-9), DQUOTE (double quote),
1389  HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed),
1390  OCTET (any 8-bit sequence of data), SP (space), and
1391  VCHAR (any visible US-ASCII character).
1392</t>
1393<t>
1394  Note that all rules derived from <x:ref>token</x:ref> are to
1395  be compared case-insensitively, like <x:ref>range-unit</x:ref> and
1396  <x:ref>acceptable-ranges</x:ref>.
1397</t>
1398<t>
1399  The rules below are defined in <xref target="Part1"/>:
1400</t>
1401<figure><artwork type="abnf2616">
1402  <x:ref>OWS</x:ref>        = &lt;OWS, defined in &whitespace;&gt;
1403  <x:ref>token</x:ref>      = &lt;token, defined in &field-components;&gt;
1404</artwork></figure>
1405<t>
1406  The rules below are defined in other parts:
1407</t>
1408<figure><artwork type="abnf2616">
1409  <x:ref>HTTP-date</x:ref>  = &lt;HTTP-date, defined in &http-date;&gt;
1410  <x:ref>entity-tag</x:ref> = &lt;entity-tag, defined in &entity-tags;&gt;
1411</artwork></figure>
1412</section> 
1413
1414<?BEGININC p5-range.abnf-appendix ?>
1415<section xmlns:x="http://purl.org/net/xml2rfc/ext" title="Collected ABNF" anchor="collected.abnf">
1416<figure>
1417<artwork type="abnf" name="p5-range.parsed-abnf">
1418<x:ref>Accept-Ranges</x:ref> = acceptable-ranges
1419
1420<x:ref>Content-Range</x:ref> = byte-content-range-spec / other-content-range-spec
1421
1422<x:ref>HTTP-date</x:ref> = &lt;HTTP-date, defined in [Part2], Section 6.1&gt;
1423
1424<x:ref>If-Range</x:ref> = entity-tag / HTTP-date
1425
1426<x:ref>OWS</x:ref> = &lt;OWS, defined in [Part1], Section 3.2.1&gt;
1427
1428<x:ref>Range</x:ref> = byte-ranges-specifier / other-ranges-specifier
1429
1430<x:ref>acceptable-ranges</x:ref> = ( *( "," OWS ) range-unit *( OWS "," [ OWS
1431 range-unit ] ) ) / "none"
1432
1433<x:ref>byte-content-range-spec</x:ref> = bytes-unit SP byte-range-resp-spec "/" (
1434 instance-length / "*" )
1435<x:ref>byte-range-resp-spec</x:ref> = ( first-byte-pos "-" last-byte-pos ) / "*"
1436<x:ref>byte-range-set</x:ref> = *( "," OWS ) ( byte-range-spec /
1437 suffix-byte-range-spec ) *( OWS "," [ OWS ( byte-range-spec /
1438 suffix-byte-range-spec ) ] )
1439<x:ref>byte-range-spec</x:ref> = first-byte-pos "-" [ last-byte-pos ]
1440<x:ref>byte-ranges-specifier</x:ref> = bytes-unit "=" byte-range-set
1441<x:ref>bytes-unit</x:ref> = "bytes"
1442
1443<x:ref>entity-tag</x:ref> = &lt;entity-tag, defined in [Part4], Section 2.3&gt;
1444
1445<x:ref>first-byte-pos</x:ref> = 1*DIGIT
1446
1447<x:ref>instance-length</x:ref> = 1*DIGIT
1448
1449<x:ref>last-byte-pos</x:ref> = 1*DIGIT
1450
1451<x:ref>other-content-range-spec</x:ref> = other-range-unit SP other-range-resp-spec
1452<x:ref>other-range-resp-spec</x:ref> = *CHAR
1453<x:ref>other-range-set</x:ref> = 1*CHAR
1454<x:ref>other-range-unit</x:ref> = token
1455<x:ref>other-ranges-specifier</x:ref> = other-range-unit "=" other-range-set
1456
1457<x:ref>range-unit</x:ref> = bytes-unit / other-range-unit
1458
1459<x:ref>suffix-byte-range-spec</x:ref> = "-" suffix-length
1460<x:ref>suffix-length</x:ref> = 1*DIGIT
1461
1462<x:ref>token</x:ref> = &lt;token, defined in [Part1], Section 3.2.4&gt;
1463</artwork>
1464</figure>
1465</section>
1466<?ENDINC p5-range.abnf-appendix ?>
1467
1468
1469<section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log">
1470<t>
1471  Changes up to the first Working Group Last Call draft are summarized
1472  in <eref target="http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-19#appendix-D"/>.
1473</t>
1474
1475<section title="Since draft-ietf-httpbis-p5-range-19" anchor="changes.since.19">
1476<t>
1477  Closed issues:
1478  <list style="symbols"> 
1479    <t>
1480      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/358"/>:
1481      "ABNF list expansion code problem"
1482    </t>
1483    <t>
1484      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/361"/>:
1485      "ABNF requirements for recipients"
1486    </t>
1487    <t>
1488      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/367"/>:
1489      "reserve 'none' as byte range unit"
1490    </t>
1491    <t>
1492      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/368"/>:
1493      "note introduction of new IANA registries as normative changes"
1494    </t>
1495    <t>
1496      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/369"/>:
1497      "range units vs leading zeroes vs size"
1498    </t>
1499  </list>
1500</t>
1501</section>
1502
1503<section title="Since draft-ietf-httpbis-p5-range-20" anchor="changes.since.20">
1504<t>
1505  None yet.
1506</t>
1507</section>
1508
1509</section>
1510
1511</back>
1512</rfc>
Note: See TracBrowser for help on using the repository browser.