source: draft-ietf-httpbis/18/draft-ietf-httpbis-p5-range-18.xml @ 1499

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

prepare for publication of -18 on Jan 04.

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