source: draft-ietf-httpbis/13/draft-ietf-httpbis-p5-range-13.xml @ 2622

Last change on this file since 2622 was 1500, checked in by julian.reschke@…, 9 years ago

fix mime types

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