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

Last change on this file since 355 was 355, checked in by ylafon@…, 11 years ago

anges relative to issue #85
removed the bias toward byte-ranges only in text that can be applied to other ranges units
fixed the BNF

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