source: draft-ietf-httpbis/16/draft-ietf-httpbis-p5-range-16.xml @ 2323

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

fix mime types

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