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

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

ABNF appendix: group by first letter, add internal links to definitions -- fix group detection (related to #36)

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