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

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

update to latest version of rfc2629.xslt, bump up document dates

  • Property svn:eol-style set to native
  • Property svn:mime-type set to text/xml
File size: 61.0 KB
[29]1<?xml version="1.0" encoding="utf-8"?>
[101]2<?xml-stylesheet type='text/xsl' href='../myxml2rfc.xslt'?>
[8]3<!DOCTYPE rfc [
4  <!ENTITY MAY "<bcp14 xmlns=''>MAY</bcp14>">
5  <!ENTITY MUST "<bcp14 xmlns=''>MUST</bcp14>">
6  <!ENTITY MUST-NOT "<bcp14 xmlns=''>MUST NOT</bcp14>">
7  <!ENTITY OPTIONAL "<bcp14 xmlns=''>OPTIONAL</bcp14>">
8  <!ENTITY RECOMMENDED "<bcp14 xmlns=''>RECOMMENDED</bcp14>">
9  <!ENTITY REQUIRED "<bcp14 xmlns=''>REQUIRED</bcp14>">
10  <!ENTITY SHALL "<bcp14 xmlns=''>SHALL</bcp14>">
11  <!ENTITY SHALL-NOT "<bcp14 xmlns=''>SHALL NOT</bcp14>">
12  <!ENTITY SHOULD "<bcp14 xmlns=''>SHOULD</bcp14>">
13  <!ENTITY SHOULD-NOT "<bcp14 xmlns=''>SHOULD NOT</bcp14>">
[29]14  <!ENTITY ID-VERSION "latest">
[1825]15  <!ENTITY ID-MONTH "August">
[1497]16  <!ENTITY ID-YEAR "2012">
[1692]17  <!ENTITY Note "<x:h xmlns:x=''>Note:</x:h>">
[1452]18  <!ENTITY architecture               "<xref target='Part1' x:rel='#architecture' xmlns:x=''/>">
[424]19  <!ENTITY notation                   "<xref target='Part1' x:rel='#notation' xmlns:x=''/>">
[1518]20  <!ENTITY abnf-extension             "<xref target='Part1' x:rel='#abnf.extension' xmlns:x=''/>">
[1364]21  <!ENTITY acks                       "<xref target='Part1' x:rel='#acks' xmlns:x=''/>">
[1518]22  <!ENTITY whitespace                 "<xref target='Part1' x:rel='#whitespace' xmlns:x=''/>">
23  <!ENTITY field-components           "<xref target='Part1' x:rel='#field.components' xmlns:x=''/>">
[1436]24  <!ENTITY http-date                  "<xref target='Part2' x:rel='' xmlns:x=''/>">
[31]25  <!ENTITY messaging                  "<xref target='Part1' xmlns:x=''/>">
[1260]26  <!ENTITY entity-tags                "<xref target='Part4' x:rel='#header.etag' xmlns:x=''/>">
[31]27  <!ENTITY weak-and-strong-validators "<xref target='Part4' x:rel='#weak.and.strong.validators' xmlns:x=''/>">
[1260]28  <!ENTITY lastmod-comparison         "<xref target='Part4' x:rel='#lastmod.comparison' xmlns:x=''/>">
[1524]29  <!ENTITY p6-heuristic               "<xref target='Part6' x:rel='#heuristic.freshness' xmlns:x=''/>">
31<?rfc toc="yes" ?>
[29]32<?rfc symrefs="yes" ?>
33<?rfc sortrefs="yes" ?>
[8]34<?rfc compact="yes"?>
35<?rfc subcompact="no" ?>
36<?rfc linkmailto="no" ?>
37<?rfc editing="no" ?>
[203]38<?rfc comments="yes"?>
39<?rfc inline="yes"?>
[799]40<?rfc rfcedstyle="yes"?>
[8]41<?rfc-ext allow-markup-in-artwork="yes" ?>
42<?rfc-ext include-references-in-index="yes" ?>
[1477]43<rfc obsoletes="2616" category="std" x:maturity-level="proposed"
44     ipr="pre5378Trust200902" docName="draft-ietf-httpbis-p5-range-&ID-VERSION;"
45     xmlns:x=''>
[1472]46<x:link rel="prev" basename="p4-conditional"/>
47<x:link rel="next" basename="p6-cache"/>
[1522]48<x:feedback template="{docname},%20%22{section}%22&amp;body=&lt;{ref}&gt;:"/>
[1803]51  <title abbrev="HTTP/1.1, Part 5">HTTP/1.1, part 5: Range Requests</title>
[29]53  <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
[1106]54    <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
[8]55    <address>
56      <postal>
[1106]57        <street>345 Park Ave</street>
58        <city>San Jose</city>
[8]59        <region>CA</region>
[1106]60        <code>95110</code>
[29]61        <country>USA</country>
[8]62      </postal>
[29]63      <email></email>
64      <uri></uri>
[8]65    </address>
66  </author>
[95]68  <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
[94]69    <organization abbrev="W3C">World Wide Web Consortium</organization>
70    <address>
71      <postal>
72        <street>W3C / ERCIM</street>
73        <street>2004, rte des Lucioles</street>
74        <city>Sophia-Antipolis</city>
75        <region>AM</region>
76        <code>06902</code>
77        <country>France</country>
78      </postal>
79      <email></email>
80      <uri></uri>
81    </address>
82  </author>
[95]84  <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
85    <organization abbrev="greenbytes">greenbytes GmbH</organization>
86    <address>
87      <postal>
88        <street>Hafenweg 16</street>
89        <city>Muenster</city><region>NW</region><code>48155</code>
90        <country>Germany</country>
91      </postal>
[609]92      <email></email>
93      <uri></uri>
[95]94    </address>
95  </author>
[31]97  <date month="&ID-MONTH;" year="&ID-YEAR;"/>
[440]98  <workgroup>HTTPbis Working Group</workgroup>
[1373]102   The Hypertext Transfer Protocol (HTTP) is an application-level protocol for
[1808]103   distributed, collaborative, hypertext information systems. This document
104   defines range requests and the rules for constructing and combining
105   responses to those requests.
109<note title="Editorial Note (To be removed by RFC Editor)">
110  <t>
[1764]111    Discussion of this draft takes place on the HTTPBIS working group
[1268]112    mailing list (, which is archived at
113    <eref target=""/>.
114  </t>
115  <t>
116    The current issues list is at
117    <eref target=""/> and related
118    documents (including fancy diffs) can be found at
[324]119    <eref target=""/>.
[36]120  </t>
[153]121  <t>
[1807]122    The changes in this draft are summarized in <xref target="changes.since.20"/>.
[153]123  </t>
127<section title="Introduction" anchor="introduction">
[158]129   HTTP clients often encounter interrupted data transfers as a result
[1776]130   of canceled requests or dropped connections.  When a client has stored
[158]131   a partial representation, it is desirable to request the remainder
132   of that representation in a subsequent request rather than transfer
133   the entire representation.
134   There are also a number of Web applications that benefit from being
135   able to request only a subset of a larger representation, such as a
136   single page of a very large document or only part of an image to be
137   rendered by a device with limited local storage.
[163]140   This document defines HTTP/1.1 range requests,
[158]141   partial responses, and the multipart/byteranges media type.
[163]142   The protocol for range requests is an &OPTIONAL; feature of HTTP,
[158]143   designed so resources or recipients that do not implement this feature
144   can respond as if it is a normal GET request without impacting
145   interoperability.  Partial responses are indicated by a distinct status
146   code to not be mistaken for full responses by intermediate caches
147   that might not implement the feature.
[163]150   Although the HTTP range request mechanism is designed to allow for
[158]151   extensible range types, this specification only defines requests for
152   byte ranges.
[1452]155<section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">
157   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
158   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
159   document are to be interpreted as described in <xref target="RFC2119"/>.
[1770]162   This specification targets conformance criteria according to the role of
163   a participant in HTTP communication.  Hence, HTTP requirements are placed
164   on senders, recipients, clients, servers, user agents, intermediaries,
165   origin servers, proxies, gateways, or caches, depending on what behavior
166   is being constrained by the requirement. See &architecture; for definitions
167   of these terms.
[1770]170   The verb "generate" is used instead of "send" where a requirement
171   differentiates between creating a protocol element and merely forwarding a
172   received element downstream.
[1452]175   An implementation is considered conformant if it complies with all of the
[1770]176   requirements associated with the roles it partakes in HTTP. Note that
177   SHOULD-level requirements are relevant here, unless one of the documented
178   exceptions is applicable.
181   This document also uses ABNF to define valid protocol elements
[1770]182   (<xref target="notation"/>).
183   In addition to the prose requirements placed upon them, senders &MUST-NOT;
184   generate protocol elements that do not match the grammar defined by the
185   ABNF rules for those protocol elements that are applicable to the sender's
186   role. If a received protocol element is processed, the recipient &MUST; be
187   able to parse any value that would match the ABNF rules for that protocol
188   element, excluding only those rules not applicable to the recipient's role.
[1770]191   Unless noted otherwise, a recipient &MAY; attempt to recover a usable
192   protocol element from an invalid construct.  HTTP does not define
193   specific error handling mechanisms except when they have a direct impact
194   on security, since different applications of the protocol require
195   different error handling strategies.  For example, a Web browser might
196   wish to transparently recover from a response where the
197   <x:ref>Location</x:ref> header field doesn't parse according to the ABNF,
198   whereas a systems control client might consider any form of error recovery
199   to be dangerous.
[424]203<section title="Syntax Notation" anchor="notation">
[1518]205   This specification uses the Augmented Backus-Naur Form (ABNF) notation
206   of <xref target="RFC5234"/> with the list rule extension defined in
[1805]207   &notation;. <xref target="imported.abnf"/> describes rules imported from
208   other documents. <xref target="collected.abnf"/> shows the collected ABNF
[1518]209   with the list rule expanded.
[8]216<section title="Range Units" anchor="range.units">
[229]217  <x:anchor-alias value="bytes-unit"/>
218  <x:anchor-alias value="other-range-unit"/>
219  <x:anchor-alias value="range-unit"/>
[1260]221   HTTP/1.1 allows a client to request that only part (a range) of the
[874]222   representation be included within the response. HTTP/1.1 uses range
[1738]223   units in the <x:ref>Range</x:ref> (<xref target="header.range"/>) and
224   <x:ref>Content-Range</x:ref> (<xref target="header.content-range"/>)
[874]225   header fields. A representation can be broken down into subranges according
[8]226   to various structural units.
228<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="range-unit"/><iref primary="true" item="Grammar" subitem="bytes-unit"/><iref primary="true" item="Grammar" subitem="other-range-unit"/>
[334]229  <x:ref>range-unit</x:ref>       = <x:ref>bytes-unit</x:ref> / <x:ref>other-range-unit</x:ref>
[229]230  <x:ref>bytes-unit</x:ref>       = "bytes"
231  <x:ref>other-range-unit</x:ref> = <x:ref>token</x:ref>
[393]234  HTTP/1.1 has been designed to allow implementations of applications
235  that do not depend on knowledge of ranges. The only range unit defined
[930]236  by HTTP/1.1 is "bytes". Additional specifiers can be defined as described
237  in <xref target="range.specifier.registry"/>.
[393]240  If a range unit is not understood in a request, a server &MUST; ignore
[1738]241  the whole <x:ref>Range</x:ref> header field (<xref target="header.range"/>).
[393]242  If a range unit is not understood in a response, an intermediary
243  &SHOULD; pass the response to the client; a client &MUST; fail.
246<section title="Range Specifier Registry" anchor="range.specifier.registry">
[1260]248   The HTTP Range Specifier Registry defines the name space for the range
[930]249   specifier names.
252   Registrations &MUST; include the following fields:
253   <list style="symbols">
254     <t>Name</t>
255     <t>Description</t>
256     <t>Pointer to specification text</t>
257   </list>
[1567]260  Values to be added to this name space require IETF Review
261  (see <xref target="RFC5226" x:fmt="," x:sec="4.1"/>).
264   The registry itself is maintained at
265   <eref target=""/>.
[838]271<section title="Status Code Definitions" anchor="status.code.definitions">
[8]272<section title="206 Partial Content" anchor="status.206">
273  <iref primary="true" item="206 Partial Content (status code)" x:for-anchor=""/>
274  <iref primary="true" item="Status Codes" subitem="206 Partial Content" x:for-anchor=""/>
[1732]275  <x:anchor-alias value="206"/>
[1708]276  <x:anchor-alias value="206 (Partial Content)"/>
278   The server has fulfilled the partial GET request for the resource.
[1738]279   The request &MUST; have included a <x:ref>Range</x:ref> header field
280   (<xref target="header.range"/>) indicating the desired range, and &MAY; have
281   included an <x:ref>If-Range</x:ref> header field
282   (<xref target="header.if-range"/>) to make the request conditional.
285   The response &MUST; include the following header fields:
286  <list style="symbols">
287    <t>
[1738]288        Either a <x:ref>Content-Range</x:ref> header field
289        (<xref target="header.content-range"/>) indicating
[8]290        the range included with this response, or a multipart/byteranges
[1740]291        <x:ref>Content-Type</x:ref> including Content-Range fields for each
292        part. If a <x:ref>Content-Length</x:ref> header field is present in the
293        response, its value &MUST; match the actual number of octets
294        transmitted in the message body.
[8]295    </t>
296    <t>
297        Date
298    </t>
299    <t>
[1739]300        <x:ref>Cache-Control</x:ref>, <x:ref>ETag</x:ref>,
[1740]301        <x:ref>Expires</x:ref>, <x:ref>Content-Location</x:ref> and/or
[1739]302        <x:ref>Vary</x:ref>, if the header field would have been sent in a
303        <x:ref>200 (OK)</x:ref> response to the same request
[8]304    </t>
305  </list>
[1738]308   If a 206 is sent in response to a request with an <x:ref>If-Range</x:ref>
309   header field, it &SHOULD-NOT; include other representation header fields.
310   Otherwise, the response &MUST; include all of the representation header
311   fields that would have been returned with a <x:ref>200 (OK)</x:ref> response
312   to the same request.
315   Caches &MAY; use a heuristic (see &p6-heuristic;) to determine
316   freshness for 206 responses.
320<section title="416 Requested Range Not Satisfiable" anchor="status.416">
321  <iref primary="true" item="416 Requested Range Not Satisfiable (status code)" x:for-anchor=""/>
322  <iref primary="true" item="Status Codes" subitem="416 Requested Range Not Satisfiable" x:for-anchor=""/>
[1708]323  <x:anchor-alias value="416 (Requested Range Not Satisfiable)"/>
325   A server &SHOULD; return a response with this status code if a request
[1738]326   included a <x:ref>Range</x:ref> header field (<xref target="header.range"/>),
327   and none of the ranges-specifier values in this field overlap the current
328   extent of the selected resource, and the request did not include an
329   <x:ref>If-Range</x:ref> header field (<xref target="header.if-range"/>).
330   (For byte-ranges, this means that the first-byte-pos of all of the
331   byte-range-spec values were greater than the current length of the selected
332   resource.)
335   When this status code is returned for a byte-range request, the
[1738]336   response &SHOULD; include a <x:ref>Content-Range</x:ref> header field
[965]337   specifying the current length of the representation (see <xref target="header.content-range"/>).
[1542]338   This response &MUST-NOT; use the multipart/byteranges content-type. For example,
[1543]340<figure><artwork type="message/http; msgtype=&#34;response&#34;" x:indent-with="  ">
341HTTP/1.1 416 Requested Range Not Satisfiable
342Date: Mon, 20 Jan 2012 15:41:54 GMT
343Content-Range: bytes */47022
344Content-Type: image/gif
347  <t>
[1708]348    &Note; Clients cannot depend on servers to send a <x:ref>416 (Requested
[1715]349    Range Not Satisfiable)</x:ref> response instead of a <x:ref>200 (OK)</x:ref>
[1738]350    response for an unsatisfiable <x:ref>Range</x:ref> header field, since not
351    all servers implement this header field.
[1542]352  </t>
[1542]357<section title="Responses to a Range Request">
358<section title="Response to a Single and Multiple Ranges Request">
360   When an HTTP message includes the content of a single range (for
361   example, a response to a request for a single range, or to a request
362   for a set of ranges that overlap without any holes), this content is
[1738]363   transmitted with a <x:ref>Content-Range</x:ref> header field, and a
[1741]364   <x:ref>Content-Length</x:ref> header field showing the number of bytes
365   actually transferred. For example,
[1543]367<figure><artwork type="message/http; msgtype=&#34;response&#34;" x:indent-with="  ">
368HTTP/1.1 206 Partial Content
369Date: Wed, 15 Nov 1995 06:25:24 GMT
370Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
371Content-Range: bytes 21010-47021/47022
372Content-Length: 26012
373Content-Type: image/gif
376   When an HTTP message includes the content of multiple ranges (for
377   example, a response to a request for multiple non-overlapping
378   ranges), these are transmitted as a multipart message. The multipart
379   media type used for this purpose is "multipart/byteranges" as defined
380   in <xref target=""/>.
383   A server &MAY; combine requested ranges when those ranges are overlapping
[1623]384   (see <xref target="overlapping.ranges"/>).
387   A response to a request for a single range &MUST-NOT; be sent using the
388   multipart/byteranges media type.  A response to a request for
389   multiple ranges, whose result is a single range, &MAY; be sent as a
390   multipart/byteranges media type with one part. A client that cannot
391   decode a multipart/byteranges message &MUST-NOT; ask for multiple
392   ranges in a single request.
[1623]395   When a client asks for multiple ranges in one request, the
[1542]396   server &SHOULD; return them in the order that they appeared in the
397   request.
[393]401<section title="Combining Ranges" anchor="combining.byte.ranges">
[1374]403   A response might transfer only a subrange of a representation if the
404   connection closed prematurely or if the request used one or more Range
405   specifications.  After several such transfers, a client might have
406   received several ranges of the same representation.  These ranges can only
407   be safely combined if they all have in common the same strong validator,
408   where "strong validator" is defined to be either an entity-tag that is
409   not marked as weak (&entity-tags;) or, if no entity-tag is provided, a
[1739]410   <x:ref>Last-Modified</x:ref> value that is strong in the sense defined by
[1374]411   &lastmod-comparison;.
[1715]414   When a client receives an incomplete <x:ref>200 (OK)</x:ref> or <x:ref>206 (Partial Content)</x:ref>
[1374]415   response and already has one or more stored responses for the same method
416   and effective request URI, all of the stored responses with the same
417   strong validator &MAY; be combined with the partial content in this new
418   response.  If none of the stored responses contain the same strong
419   validator, then this new response corresponds to a new representation
420   and &MUST-NOT; be combined with the existing stored responses.
[1715]423   If the new response is an incomplete <x:ref>200 (OK)</x:ref> response, then the header
[1374]424   fields of that new response are used for any combined response and replace
425   those of the matching stored responses.
[1708]428   If the new response is a <x:ref>206 (Partial Content)</x:ref> response and at least one
[1715]429   of the matching stored responses is a <x:ref>200 (OK)</x:ref>, then the combined response
[1374]430   header fields consist of the most recent 200 response's header fields.
[1735]431   If all of the matching stored responses are 206 responses, then the
[1374]432   stored response with the most header fields is used as the source of
433   header fields for the combined response, except that the client &MUST;
434   use other header fields provided in the new response, aside from
[1738]435   <x:ref>Content-Range</x:ref>, to replace all instances of the corresponding
436   header fields in the stored response.
[1544]439   The combined response message body consists of the union of partial
[1374]440   content ranges in the new response and each of the selected responses.
441   If the union consists of the entire range of the representation, then the
[1741]442   combined response &MUST; be recorded as a complete <x:ref>200 (OK)</x:ref>
443   response with a <x:ref>Content-Length</x:ref> header field that reflects the
444   complete length. Otherwise, the combined response(s) &MUST; include a
445   <x:ref>Content-Range</x:ref> header field describing the included range(s)
446   and be recorded as incomplete.  If the union consists of a discontinuous
447   range of the representation, then the client &MAY; store it as either a
448   multipart range response or as multiple <x:ref>206</x:ref> responses with
449   one continuous range each.
[1415]454<section title="Header Field Definitions" anchor="header.field.definitions">
[117]456   This section defines the syntax and semantics of HTTP/1.1 header fields
457   related to range requests and partial responses.
[8]460<section title="Accept-Ranges" anchor="header.accept-ranges">
[1120]461  <iref primary="true" item="Accept-Ranges header field" x:for-anchor=""/>
462  <iref primary="true" item="Header Fields" subitem="Accept-Ranges" x:for-anchor=""/>
[229]463  <x:anchor-alias value="Accept-Ranges"/>
464  <x:anchor-alias value="acceptable-ranges"/>
[1163]466   The "Accept-Ranges" header field allows a resource to indicate
[698]467   its acceptance of range requests.
[1232]469<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Ranges"/><iref primary="true" item="Grammar" subitem="acceptable-ranges"/>
470  <x:ref>Accept-Ranges</x:ref>     = <x:ref>acceptable-ranges</x:ref>
[334]471  <x:ref>acceptable-ranges</x:ref> = 1#<x:ref>range-unit</x:ref> / "none"
[1772]474   Origin servers that accept byte-range requests &MAY; send
476<figure><artwork type="example">
[363]477  Accept-Ranges: bytes
[1772]480   but are not required to do so. Clients &MAY; generate range
481   requests without having received this header field for the resource
482   involved. Range units are defined in <xref target="range.units"/>.
[1772]485   Servers that do not accept any kind of range request for a
486   resource &MAY; send
488<figure><artwork type="example">
[363]489  Accept-Ranges: none
[1772]492   to advise the client not to attempt a range request.
496<section title="Content-Range" anchor="header.content-range">
[1120]497  <iref primary="true" item="Content-Range header field" x:for-anchor=""/>
498  <iref primary="true" item="Header Fields" subitem="Content-Range" x:for-anchor=""/>
[229]499  <x:anchor-alias value="byte-content-range-spec"/>
500  <x:anchor-alias value="byte-range-resp-spec"/>
501  <x:anchor-alias value="Content-Range"/>
502  <x:anchor-alias value="instance-length"/>
[393]503  <x:anchor-alias value="other-content-range-spec"/>
504  <x:anchor-alias value="other-range-resp-spec"/>
[965]506   The "Content-Range" header field is sent with a partial representation to
[969]507   specify where in the full representation the payload body is intended to be
[962]508   applied.
511   Range units are defined in <xref target="range.units"/>.
[1398]513<figure><artwork type="abnf2616"><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"/>
514  <x:ref>Content-Range</x:ref>           = <x:ref>byte-content-range-spec</x:ref>
[434]515                          / <x:ref>other-content-range-spec</x:ref>
[229]517  <x:ref>byte-content-range-spec</x:ref> = <x:ref>bytes-unit</x:ref> <x:ref>SP</x:ref>
518                            <x:ref>byte-range-resp-spec</x:ref> "/"
[334]519                            ( <x:ref>instance-length</x:ref> / "*" )
[304]521  <x:ref>byte-range-resp-spec</x:ref>    = (<x:ref>first-byte-pos</x:ref> "-" <x:ref>last-byte-pos</x:ref>)
[334]522                          / "*"
524  <x:ref>instance-length</x:ref>         = 1*<x:ref>DIGIT</x:ref>
526  <x:ref>other-content-range-spec</x:ref> = <x:ref>other-range-unit</x:ref> <x:ref>SP</x:ref>
527                             <x:ref>other-range-resp-spec</x:ref>
528  <x:ref>other-range-resp-spec</x:ref>    = *<x:ref>CHAR</x:ref>
[994]531   The header field &SHOULD; indicate the total length of the full representation,
[8]532   unless this length is unknown or difficult to determine. The asterisk
533   "*" character means that the instance-length is unknown at the time
534   when the response was generated.
537   Unlike byte-ranges-specifier values (see <xref target="byte.ranges"/>), a byte-range-resp-spec
538   &MUST; only specify one range, and &MUST; contain
539   absolute byte positions for both the first and last byte of the
540   range.
543   A byte-content-range-spec with a byte-range-resp-spec whose last-byte-pos
544   value is less than its first-byte-pos value, or whose
545   instance-length value is less than or equal to its last-byte-pos
546   value, is invalid. The recipient of an invalid byte-content-range-spec
547   &MUST; ignore it and any content transferred along with it.
[393]550   In the case of a byte range request:
[1708]551   A server sending a response with status code <x:ref>416 (Requested Range Not
552   Satisfiable)</x:ref> &SHOULD; include a Content-Range field with a byte-range-resp-spec
[8]553   of "*". The instance-length specifies the current length of
[1708]554   the selected resource. A response with status code <x:ref>206 (Partial Content)</x:ref>
555   &MUST-NOT; include a Content-Range field with a byte-range-resp-spec of "*".
[1461]558  The "Content-Range" header field has no meaning for status codes that do not
[1459]559  explicitly describe its semantic. Currently, only status codes
[1708]560  <x:ref>206 (Partial Content)</x:ref> and <x:ref>416 (Requested Range Not Satisfiable)</x:ref> describe
[1459]561  the meaning of this header field.
[866]564   Examples of byte-content-range-spec values, assuming that the representation
[8]565   contains a total of 1234 bytes:
566   <list style="symbols">
567      <t>
568        The first 500 bytes:
[565]569<figure><artwork type="example" x:indent-with="   ">
570  bytes 0-499/1234
572      </t>   
573      <t>
574        The second 500 bytes:
[565]575<figure><artwork type="example" x:indent-with="   ">
576  bytes 500-999/1234
578      </t>   
579      <t>
580        All except for the first 500 bytes:
[565]581<figure><artwork type="example" x:indent-with="   ">
582  bytes 500-1233/1234
584      </t>   
585      <t>
586        The last 500 bytes:
[565]587<figure><artwork type="example" x:indent-with="   ">
588  bytes 734-1233/1234
590      </t>   
591   </list>
[1542]594   If the server ignores a byte-range-spec (for example if it is
[1685]595   syntactically invalid, or if it might be seen as a denial-of-service
[1738]596   attack), the server &SHOULD; treat the request as if the invalid <x:ref>Range</x:ref>
[1715]597   header field did not exist. (Normally, this means return a <x:ref>200 (OK)</x:ref>
[874]598   response containing the full representation).
602<section title="If-Range" anchor="header.if-range">
[1120]603  <iref primary="true" item="If-Range header field" x:for-anchor=""/>
604  <iref primary="true" item="Header Fields" subitem="If-Range" x:for-anchor=""/>
[229]605  <x:anchor-alias value="If-Range"/>
[1374]607   If a client has a partial copy of a representation and wishes
[1738]608   to have an up-to-date copy of the entire representation, it could use the
609   <x:ref>Range</x:ref> header field with a conditional GET (using
[1739]610   either or both of <x:ref>If-Unmodified-Since</x:ref> and
611   <x:ref>If-Match</x:ref>.) However, if the condition fails because the
612   representation has been modified, the client would then have to make a
613   second request to obtain the entire current representation.
[1163]616   The "If-Range" header field allows a client to "short-circuit" the second
[866]617   request. Informally, its meaning is "if the representation is unchanged, send
[8]618   me the part(s) that I am missing; otherwise, send me the entire new
[866]619   representation".
[1232]621<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Range"/>
622  <x:ref>If-Range</x:ref> = <x:ref>entity-tag</x:ref> / <x:ref>HTTP-date</x:ref>
[1374]625   Clients &MUST-NOT; use an entity-tag marked as weak in an If-Range
[1739]626   field value and &MUST-NOT; use a <x:ref>Last-Modified</x:ref> date in an
627   If-Range field value unless it has no entity-tag for the representation and
[1374]628   the Last-Modified date it does have for the representation is strong
629   in the sense defined by &lastmod-comparison;.
[1374]632   A server that evaluates a conditional range request that is applicable
633   to one of its representations &MUST; evaluate the condition as false if
634   the entity-tag used as a validator is marked as weak or, when an HTTP-date
635   is used as the validator, if the date value is not strong in the sense
636   defined by &lastmod-comparison;. (A server can distinguish between a
637   valid HTTP-date and any form of entity-tag by examining the first
638   two characters.)
[1374]641   The If-Range header field &SHOULD; only be sent by clients together with
642   a Range header field.  The If-Range header field &MUST; be ignored if it
643   is received in a request that does not include a Range header field.
644   The If-Range header field &MUST; be ignored by a server that does not
645   support the sub-range operation.
[1374]648   If the validator given in the If-Range header field matches the current
649   validator for the selected representation of the target resource, then
650   the server &SHOULD; send the specified sub-range of the representation
[1708]651   using a <x:ref>206 (Partial Content)</x:ref> response. If the validator does not match,
[1715]652   then the server &SHOULD; send the entire representation using a <x:ref>200 (OK)</x:ref>
[1374]653   response.
657<section title="Range" anchor="header.range">
[1120]658  <iref primary="true" item="Range header field" x:for-anchor=""/>
659  <iref primary="true" item="Header Fields" subitem="Range" x:for-anchor=""/>
661<section title="Byte Ranges" anchor="byte.ranges">
[866]663   Since all HTTP representations are transferred as sequences
[8]664   of bytes, the concept of a byte range is meaningful for any HTTP
[866]665   representation. (However, not all clients and servers need to support byte-range
[8]666   operations.)
669   Byte range specifications in HTTP apply to the sequence of bytes in
[1544]670   the representation body (not necessarily the same as the message body).
[229]672<t anchor="rule.ranges-specifier">
673  <x:anchor-alias value="byte-range-set"/>
674  <x:anchor-alias value="byte-range-spec"/>
675  <x:anchor-alias value="byte-ranges-specifier"/>
676  <x:anchor-alias value="first-byte-pos"/>
677  <x:anchor-alias value="last-byte-pos"/>
678  <x:anchor-alias value="ranges-specifier"/>
679  <x:anchor-alias value="suffix-byte-range-spec"/>
680  <x:anchor-alias value="suffix-length"/>
[8]681   A byte range operation &MAY; specify a single range of bytes, or a set
[866]682   of ranges within a single representation.
684<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="ranges-specifier"/><iref primary="true" item="Grammar" subitem="byte-ranges-specifier"/><iref primary="true" item="Grammar" subitem="byte-range-set"/><iref primary="true" item="Grammar" subitem="byte-range-spec"/><iref primary="true" item="Grammar" subitem="first-byte-pos"/><iref primary="true" item="Grammar" subitem="last-byte-pos"/>
[229]685  <x:ref>byte-ranges-specifier</x:ref> = <x:ref>bytes-unit</x:ref> "=" <x:ref>byte-range-set</x:ref>
[334]686  <x:ref>byte-range-set</x:ref>  = 1#( <x:ref>byte-range-spec</x:ref> / <x:ref>suffix-byte-range-spec</x:ref> )
[434]687  <x:ref>byte-range-spec</x:ref> = <x:ref>first-byte-pos</x:ref> "-" [ <x:ref>last-byte-pos</x:ref> ]
[229]688  <x:ref>first-byte-pos</x:ref>  = 1*<x:ref>DIGIT</x:ref>
689  <x:ref>last-byte-pos</x:ref>   = 1*<x:ref>DIGIT</x:ref>
692   The first-byte-pos value in a byte-range-spec gives the byte-offset
693   of the first byte in a range. The last-byte-pos value gives the
694   byte-offset of the last byte in the range; that is, the byte
[576]695   positions specified are inclusive. Byte offsets start at zero.
698   If the last-byte-pos value is present, it &MUST; be greater than or
699   equal to the first-byte-pos in that byte-range-spec, or the byte-range-spec
700   is syntactically invalid. The recipient of a byte-range-set
701   that includes one or more syntactically invalid byte-range-spec
702   values &MUST; ignore the header field that includes that byte-range-set.
705   If the last-byte-pos value is absent, or if the value is greater than
[866]706   or equal to the current length of the representation body, last-byte-pos is
707   taken to be equal to one less than the current length of the representation
[8]708   in bytes.
711   By its choice of last-byte-pos, a client can limit the number of
[866]712   bytes retrieved without knowing the size of the representation.
714<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="suffix-byte-range-spec"/><iref primary="true" item="Grammar" subitem="suffix-length"/>
[229]715  <x:ref>suffix-byte-range-spec</x:ref> = "-" <x:ref>suffix-length</x:ref>
716  <x:ref>suffix-length</x:ref> = 1*<x:ref>DIGIT</x:ref>
719   A suffix-byte-range-spec is used to specify the suffix of the
[866]720   representation body, of a length given by the suffix-length value. (That is,
[874]721   this form specifies the last N bytes of a representation.) If the
[866]722   representation is shorter than the specified suffix-length, the entire
723   representation is used.
726   If a syntactically valid byte-range-set includes at least one byte-range-spec
727   whose first-byte-pos is less than the current length of
[874]728   the representation, or at least one suffix-byte-range-spec with a non-zero
[8]729   suffix-length, then the byte-range-set is satisfiable.
730   Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set
[926]731   is unsatisfiable, the server &SHOULD; return a response with a
[1708]732   <x:ref>416 (Requested Range Not Satisfiable)</x:ref> status code. Otherwise, the server
733   &SHOULD; return a response with a <x:ref>206 (Partial Content)</x:ref> status code
[866]734   containing the satisfiable ranges of the representation.
[1767]737   In the byte range syntax, <x:ref>first-byte-pos</x:ref>,
738   <x:ref>last-byte-pos</x:ref>, and <x:ref>suffix-length</x:ref> are
739   expressed as decimal number of octets.  Since there is no predefined limit
740   to the length of an HTTP payload, recipients &SHOULD; anticipate
741   potentially large decimal numerals and prevent parsing errors due to integer
742   conversion overflows.
[874]745   Examples of byte-ranges-specifier values (assuming a representation of
[8]746   length 10000):
747  <list style="symbols">
[565]748     <t>The first 500 bytes (byte offsets 0-499, inclusive):
749<figure><artwork type="example" x:indent-with="   ">
750  bytes=0-499
752    </t>
[8]753     <t>The second 500 bytes (byte offsets 500-999, inclusive):
[565]754<figure><artwork type="example" x:indent-with="   ">
755  bytes=500-999
757    </t>
[8]758     <t>The final 500 bytes (byte offsets 9500-9999, inclusive):
[565]759<figure><artwork type="example" x:indent-with="   ">
760  bytes=-500
762    Or:
763<figure><artwork type="example" x:indent-with="   ">
764  bytes=9500-
766    </t>
767     <t>The first and last bytes only (bytes 0 and 9999):
768<figure><artwork type="example" x:indent-with="   ">
769  bytes=0-0,-1
771     </t>
[8]772     <t>Several legal but not canonical specifications of the second 500
773        bytes (byte offsets 500-999, inclusive):
[565]774<figure><artwork type="example" x:indent-with="   ">
775  bytes=500-600,601-999
776  bytes=500-700,601-999
778     </t>
[8]779  </list>
783<section title="Range Retrieval Requests" anchor="range.retrieval.requests">
[229]784  <x:anchor-alias value="Range"/>
[564]785  <x:anchor-alias value="other-ranges-specifier"/>
[637]786  <x:anchor-alias value="other-range-set"/>
[1163]788   The "Range" header field defines the GET method (conditional or
[866]789   not) to request one or more sub-ranges of the response representation body, instead
790   of the entire representation body.
[393]792<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Range"/>
[1232]793  <x:ref>Range</x:ref> = <x:ref>byte-ranges-specifier</x:ref> / <x:ref>other-ranges-specifier</x:ref>
[637]794  <x:ref>other-ranges-specifier</x:ref> = <x:ref>other-range-unit</x:ref> "=" <x:ref>other-range-set</x:ref>
795  <x:ref>other-range-set</x:ref> = 1*<x:ref>CHAR</x:ref>
[1374]798   A server &MAY; ignore the Range header field. However, origin
[8]799   servers and intermediate caches ought to support byte ranges when
800   possible, since Range supports efficient recovery from partially
801   failed transfers, and supports efficient partial retrieval of large
[874]802   representations.
[994]805   If the server supports the Range header field and the specified range or
[874]806   ranges are appropriate for the representation:
[8]807  <list style="symbols">
[994]808     <t>The presence of a Range header field in an unconditional GET modifies
[8]809        what is returned if the GET is otherwise successful. In other
[1708]810        words, the response carries a status code of <x:ref>206 (Partial Content)</x:ref>
[1715]811        instead of <x:ref>200 (OK)</x:ref>.</t>
[994]813     <t>The presence of a Range header field in a conditional GET (a request
[1739]814        using one or both of <x:ref>If-Modified-Since</x:ref> and
815        <x:ref>If-None-Match</x:ref>, or one or both of
816        <x:ref>If-Unmodified-Since</x:ref> and <x:ref>If-Match</x:ref>) modifies
817        what is returned if the GET is otherwise successful and the
[1734]818        condition is true. It does not affect the <x:ref>304 (Not Modified)</x:ref>
[8]819        response returned if the conditional is false.</t>
820  </list>
823   In some cases, it might be more appropriate to use the If-Range
[994]824   header field (see <xref target="header.if-range"/>) in addition to the Range
825   header field.
[1014]828   If a proxy that supports ranges receives a Range request, forwards
[874]829   the request to an inbound server, and receives an entire representation in
[1014]830   reply, it &MAY; only return the requested range to its client.
[29]836<section title="IANA Considerations" anchor="IANA.considerations">
838<section title="Status Code Registration" anchor="status.code.registration">
840   The HTTP Status Code Registry located at <eref target=""/>
[969]841   shall be updated with the registrations below:
843<?BEGININC p5-range.iana-status-codes ?>
844<!--AUTOGENERATED FROM extract-status-code-defs.xslt, do not edit manually-->
845<texttable align="left" suppress-title="true" anchor="iana.status.code.registration.table">
846   <ttcol>Value</ttcol>
847   <ttcol>Description</ttcol>
848   <ttcol>Reference</ttcol>
849   <c>206</c>
850   <c>Partial Content</c>
851   <c>
852      <xref target="status.206"/>
853   </c>
854   <c>416</c>
855   <c>Requested Range Not Satisfiable</c>
856   <c>
857      <xref target="status.416"/>
858   </c>
861<?ENDINC p5-range.iana-status-codes ?>
[921]864<section title="Header Field Registration" anchor="header.field.registration">
[969]866   The Message Header Field Registry located at <eref target=""/> shall be updated
[290]867   with the permanent registrations below (see <xref target="RFC3864"/>):
[680]869<?BEGININC p5-range.iana-headers ?>
[253]870<!--AUTOGENERATED FROM extract-header-defs.xslt, do not edit manually-->
[290]871<texttable align="left" suppress-title="true" anchor="iana.header.registration.table">
[253]872   <ttcol>Header Field Name</ttcol>
873   <ttcol>Protocol</ttcol>
874   <ttcol>Status</ttcol>
875   <ttcol>Reference</ttcol>
877   <c>Accept-Ranges</c>
878   <c>http</c>
879   <c>standard</c>
880   <c>
881      <xref target="header.accept-ranges"/>
882   </c>
883   <c>Content-Range</c>
884   <c>http</c>
885   <c>standard</c>
886   <c>
887      <xref target="header.content-range"/>
888   </c>
889   <c>If-Range</c>
890   <c>http</c>
891   <c>standard</c>
892   <c>
893      <xref target="header.if-range"/>
894   </c>
895   <c>Range</c>
896   <c>http</c>
897   <c>standard</c>
898   <c>
899      <xref target="header.range"/>
900   </c>
[680]903<?ENDINC p5-range.iana-headers ?>
[290]905   The change controller is: "IETF ( - Internet Engineering Task Force".
909<section title="Range Specifier Registration" anchor="range.specifier.registration">
911  The registration procedure for HTTP Range Specifiers is defined by
912  <xref target="range.specifier.registry"/> of this document.
[969]915   The HTTP Range Specifier Registry shall be created at <eref target=""/>
[930]916   and be populated with the registrations below:
918<texttable align="left" suppress-title="true" anchor="iana.range.specifiers.table">
919   <ttcol>Range Specifier Name</ttcol>
920   <ttcol>Description</ttcol>
921   <ttcol>Reference</ttcol>
923   <c>bytes</c>
924   <c>a range of octets</c>
[1748]925   <c><xref target="range.units"/></c>
927   <c>none</c>
928   <c>reserved as keyword, indicating no ranges are supported</c>
929   <c><xref target="header.accept-ranges"/></c>
932   The change controller is: "IETF ( - Internet Engineering Task Force".
937<section title="Security Considerations" anchor="security.considerations">
[1355]939   This section is meant to inform application developers, information
940   providers, and users of the security limitations in HTTP/1.1 as
941   described by this document. The discussion does not include
942   definitive solutions to the problems revealed, though it does make
943   some suggestions for reducing security risks.
[1355]945<section title="Overlapping Ranges" anchor="overlapping.ranges">
[1685]947   Range requests containing overlapping ranges can lead to the situation
[1355]948   where a server is sending far more data than the size of the complete
949   resource representation.
[1364]954<section title="Acknowledgments" anchor="acks">
[1364]956  See &acks;.
[119]962<references title="Normative References">
[31]964<reference anchor="Part1">
[119]965  <front>
[1803]966    <title>HTTP/1.1, part 1: Message Routing and Syntax"</title>
[119]967    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
[1106]968      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
[119]969      <address><email></email></address>
970    </author>
971    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
972      <organization abbrev="W3C">World Wide Web Consortium</organization>
973      <address><email></email></address>
974    </author>
975    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
976      <organization abbrev="greenbytes">greenbytes GmbH</organization>
977      <address><email></email></address>
978    </author>
979    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
980  </front>
981  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-&ID-VERSION;"/>
[1740]982  <x:source href="p1-messaging.xml" basename="p1-messaging">
983    <x:defines>Content-Length</x:defines>
984  </x:source>
[1436]987<reference anchor="Part2">
988  <front>
[1803]989    <title>HTTP/1.1, part 2: Semantics and Payloads</title>
[1436]990    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
991      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
992      <address><email></email></address>
993    </author>
994    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
995      <organization abbrev="W3C">World Wide Web Consortium</organization>
996      <address><email></email></address>
997    </author>
998    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
999      <organization abbrev="greenbytes">greenbytes GmbH</organization>
1000      <address><email></email></address>
1001    </author>
1002    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
1003  </front>
1004  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;"/>
[1715]1005  <x:source href="p2-semantics.xml" basename="p2-semantics">
1006    <x:defines>200 (OK)</x:defines>
[1735]1007    <x:defines>410 (Gone)</x:defines>
[1740]1008    <x:defines>Content-Location</x:defines>
1009    <x:defines>Content-Type</x:defines>
1010    <x:defines>Location</x:defines>
[1715]1011  </x:source>
[31]1014<reference anchor="Part4">
[119]1015  <front>
[1726]1016    <title>HTTP/1.1, part 4: Conditional Requests</title>
[119]1017    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
[1106]1018      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
[119]1019      <address><email></email></address>
1020    </author>
1021    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
1022      <organization abbrev="W3C">World Wide Web Consortium</organization>
1023      <address><email></email></address>
1024    </author>
1025    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
1026      <organization abbrev="greenbytes">greenbytes GmbH</organization>
1027      <address><email></email></address>
1028    </author>
1029    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
1030  </front>
1031  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p4-conditional-&ID-VERSION;"/>
[1734]1032  <x:source href="p4-conditional.xml" basename="p4-conditional">
1033    <x:defines>304 (Not Modified)</x:defines>
[1739]1034    <x:defines>ETag</x:defines>
1035    <x:defines>If-Match</x:defines>
1036    <x:defines>If-Modified-Since</x:defines>
1037    <x:defines>If-None-Match</x:defines>
1038    <x:defines>If-Unmodified-Since</x:defines>
1039    <x:defines>Last-Modified</x:defines>
[1734]1040  </x:source>
[1524]1043<reference anchor="Part6">
1044  <front>
[1726]1045    <title>HTTP/1.1, part 6: Caching</title>
[1524]1046    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
1047      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
1048      <address><email></email></address>
1049    </author>
1050    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
1051      <organization abbrev="W3C">World Wide Web Consortium</organization>
1052      <address><email></email></address>
1053    </author>
1054    <author initials="M." surname="Nottingham" fullname="Mark Nottingham" role="editor">
1055      <organization>Rackspace</organization>
1056      <address><email></email></address>
1057    </author>
1058    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
1059      <organization abbrev="greenbytes">greenbytes GmbH</organization>
1060      <address><email></email></address>
1061    </author>
1062    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
1063  </front>
1064  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-&ID-VERSION;"/>
[1737]1065  <x:source href="p6-cache.xml" basename="p6-cache">
[1739]1066    <x:defines>Cache-Control</x:defines>
[1737]1067    <x:defines>Expires</x:defines>
[1739]1068    <x:defines>Vary</x:defines>
[1737]1069  </x:source>
[131]1072<reference anchor="RFC2046">
1073  <front>
1074    <title abbrev="Media Types">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</title>
1075    <author initials="N." surname="Freed" fullname="Ned Freed">
1076      <organization>Innosoft International, Inc.</organization>
1077      <address><email></email></address>
1078    </author>
1079    <author initials="N." surname="Borenstein" fullname="Nathaniel S. Borenstein">
1080      <organization>First Virtual Holdings</organization>
1081      <address><email></email></address>
1082    </author>
1083    <date month="November" year="1996"/>
1084  </front>
1085  <seriesInfo name="RFC" value="2046"/>
[119]1088<reference anchor="RFC2119">
1089  <front>
1090    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
1091    <author initials="S." surname="Bradner" fullname="Scott Bradner">
1092      <organization>Harvard University</organization>
1093      <address><email></email></address>
1094    </author>
1095    <date month="March" year="1997"/>
1096  </front>
1097  <seriesInfo name="BCP" value="14"/>
1098  <seriesInfo name="RFC" value="2119"/>
[425]1101<reference anchor="RFC5234">
1102  <front>
1103    <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title>
1104    <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor">
1105      <organization>Brandenburg InternetWorking</organization>
1106      <address>
[728]1107        <email></email>
1108      </address> 
[425]1109    </author>
1110    <author initials="P." surname="Overell" fullname="Paul Overell">
1111      <organization>THUS plc.</organization>
1112      <address>
[728]1113        <email></email>
1114      </address>
[425]1115    </author>
1116    <date month="January" year="2008"/>
1117  </front>
1118  <seriesInfo name="STD" value="68"/>
1119  <seriesInfo name="RFC" value="5234"/>
1124<references title="Informative References">
[36]1126<reference anchor="RFC2616">
[119]1127  <front>
1128    <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
1129    <author initials="R." surname="Fielding" fullname="R. Fielding">
1130      <organization>University of California, Irvine</organization>
1131      <address><email></email></address>
1132    </author>
1133    <author initials="J." surname="Gettys" fullname="J. Gettys">
1134      <organization>W3C</organization>
1135      <address><email></email></address>
1136    </author>
1137    <author initials="J." surname="Mogul" fullname="J. Mogul">
1138      <organization>Compaq Computer Corporation</organization>
1139      <address><email></email></address>
1140    </author>
1141    <author initials="H." surname="Frystyk" fullname="H. Frystyk">
1142      <organization>MIT Laboratory for Computer Science</organization>
1143      <address><email></email></address>
1144    </author>
1145    <author initials="L." surname="Masinter" fullname="L. Masinter">
1146      <organization>Xerox Corporation</organization>
1147      <address><email></email></address>
1148    </author>
1149    <author initials="P." surname="Leach" fullname="P. Leach">
1150      <organization>Microsoft Corporation</organization>
1151      <address><email></email></address>
1152    </author>
1153    <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
1154      <organization>W3C</organization>
1155      <address><email></email></address>
1156    </author>
1157    <date month="June" year="1999"/>
1158  </front>
1159  <seriesInfo name="RFC" value="2616"/>
[253]1162<reference anchor='RFC3864'>
1163  <front>
1164    <title>Registration Procedures for Message Header Fields</title>
1165    <author initials='G.' surname='Klyne' fullname='G. Klyne'>
1166      <organization>Nine by Nine</organization>
1167      <address><email></email></address>
1168    </author>
1169    <author initials='M.' surname='Nottingham' fullname='M. Nottingham'>
1170      <organization>BEA Systems</organization>
1171      <address><email></email></address>
1172    </author>
1173    <author initials='J.' surname='Mogul' fullname='J. Mogul'>
1174      <organization>HP Labs</organization>
1175      <address><email></email></address>
1176    </author>
1177    <date year='2004' month='September' />
1178  </front>
1179  <seriesInfo name='BCP' value='90' />
1180  <seriesInfo name='RFC' value='3864' />
[196]1183<reference anchor="RFC4288">
1184  <front>
1185    <title>Media Type Specifications and Registration Procedures</title>
1186    <author initials="N." surname="Freed" fullname="N. Freed">
1187      <organization>Sun Microsystems</organization>
1188      <address>
1189        <email></email>
1190      </address>
1191    </author>
1192    <author initials="J." surname="Klensin" fullname="J. Klensin">
1193      <address>
1194        <email></email>
1195      </address>
1196    </author>
1197    <date year="2005" month="December"/>
1198  </front>
1199  <seriesInfo name="BCP" value="13"/>
1200  <seriesInfo name="RFC" value="4288"/>
[930]1203<reference anchor='RFC5226'>
1204  <front>
1205    <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
1206    <author initials='T.' surname='Narten' fullname='T. Narten'>
1207      <organization>IBM</organization>
1208      <address><email></email></address>
1209    </author>
1210    <author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'>
1211      <organization>Google</organization>
1212      <address><email></email></address>
1213    </author>
1214    <date year='2008' month='May' />
1215  </front>
1216  <seriesInfo name='BCP' value='26' />
1217  <seriesInfo name='RFC' value='5226' />
[8]1222<section title="Internet Media Type multipart/byteranges" anchor="">
1223<iref item="Media Type" subitem="multipart/byteranges" primary="true"/>
1224<iref item="multipart/byteranges Media Type" primary="true"/>
[1708]1226   When an HTTP <x:ref>206 (Partial Content)</x:ref> response message includes the
[8]1227   content of multiple ranges (a response to a request for multiple
1228   non-overlapping ranges), these are transmitted as a multipart
[1544]1229   message body (<xref target="RFC2046" x:fmt="," x:sec="5.1"/>). The media type for this purpose is called
[196]1230   "multipart/byteranges".  The following is to be registered with IANA <xref target="RFC4288"/>.
[332]1233   The multipart/byteranges media type includes one or more parts, each
[1740]1234   with its own <x:ref>Content-Type</x:ref> and <x:ref>Content-Range</x:ref>
1235   fields. The required boundary parameter specifies the boundary string used
1236   to separate each body-part.
1239  <list style="hanging" x:indent="12em">
[196]1240    <t hangText="Type name:">
[8]1241      multipart
1242    </t>
[196]1243    <t hangText="Subtype name:">
[8]1244      byteranges
1245    </t>
1246    <t hangText="Required parameters:">
1247      boundary
1248    </t>
1249    <t hangText="Optional parameters:">
1250      none
1251    </t>
1252    <t hangText="Encoding considerations:">
1253      only "7bit", "8bit", or "binary" are permitted
1254    </t>
1255    <t hangText="Security considerations:">
1256      none
1257    </t>
[196]1258    <t hangText="Interoperability considerations:">
1259      none
1260    </t>
1261    <t hangText="Published specification:">
1262      This specification (see <xref target=""/>).
1263    </t>
1264    <t hangText="Applications that use this media type:">
[1749]1265      HTTP components supporting multiple ranges in a single request.
[196]1266    </t>
1267    <t hangText="Additional information:">
1268      <list style="hanging">
1269        <t hangText="Magic number(s):">none</t>
1270        <t hangText="File extension(s):">none</t>
1271        <t hangText="Macintosh file type code(s):">none</t>
1272      </list>
1273    </t>
1274    <t hangText="Person and email address to contact for further information:">
1275      See Authors Section.
1276    </t>
[609]1277    <t hangText="Intended usage:">
1278      COMMON
[196]1279    </t>
[609]1280    <t hangText="Restrictions on usage:">
1281      none
[196]1282    </t>
1283    <t hangText="Author/Change controller:">
1284      IESG
1285    </t>
[8]1286  </list>
1289  <t>
1290    &Note; Despite the name "multipart/byteranges" is not limited to the byte ranges only.
1291  </t>
1294   For example:
1295</preamble><artwork type="example">
[435]1296  HTTP/1.1 206 Partial Content
1297  Date: Wed, 15 Nov 1995 06:25:24 GMT
1298  Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
1299  Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
1302  Content-type: application/pdf
1303  Content-range: bytes 500-999/8000
1305  ...the first range...
1307  Content-type: application/pdf
1308  Content-range: bytes 7000-7999/8000
1310  ...the second range
[1749]1314   Another example, using the "exampleunit" range unit:
1316<artwork type="example">
1317  HTTP/1.1 206 Partial Content
1318  Date: Tue, 14 Nov 1995 06:25:24 GMT
1319  Last-Modified: Tue, 14 July 04:58:08 GMT
1320  Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
1323  Content-type: video/example
1324  Content-range: exampleunit 1.2-4.3/25
1326  ...the first range...
[645]1328  Content-type: video/example
1329  Content-range: exampleunit 11.2-14.3/25
1331  ...the second range
[1749]1336  Notes:
[8]1337  <list style="numbers">
[908]1338      <t>Additional CRLFs &MAY; precede the first boundary string in the body.</t>
[97]1340      <t>Although <xref target="RFC2046"/> permits the boundary string to be
[8]1341         quoted, some existing implementations handle a quoted boundary
1342         string incorrectly.</t>
[1600]1344      <t>A number of clients and servers were coded to an early draft
[8]1345         of the byteranges specification to use a media type of
1346         multipart/x-byteranges<iref item="multipart/x-byteranges Media Type"/><iref item="Media Type" subitem="multipart/x-byteranges"/>, which is almost, but not quite
1347         compatible with the version documented in HTTP/1.1.</t>
1348  </list>
[99]1352<section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">
[1760]1354  Introduce Range Specifier Registry.
1355  (<xref target="range.specifier.registry"/>)
[1732]1358  Clarify that it is not ok to use a weak validator in a <x:ref>206</x:ref> response.
[105]1359  (<xref target="status.206"/>)
[1232]1362  Change ABNF productions for header fields to only define the field value.
[1415]1363  (<xref target="header.field.definitions"/>)
[332]1366  Clarify that multipart/byteranges can consist of a single part.
1367  (<xref target=""/>)
[1805]1371<section title="Imported ABNF" anchor="imported.abnf">
1372  <x:anchor-alias value="ALPHA"/>
1373  <x:anchor-alias value="CHAR"/>
1374  <x:anchor-alias value="CR"/>
1375  <x:anchor-alias value="DIGIT"/>
1376  <x:anchor-alias value="LF"/>
1377  <x:anchor-alias value="OCTET"/>
1378  <x:anchor-alias value="SP"/>
1379  <x:anchor-alias value="VCHAR"/>
1380  <x:anchor-alias value="token"/>
1381  <x:anchor-alias value="OWS"/>
1382  <x:anchor-alias value="HTTP-date"/>
1383  <x:anchor-alias value="entity-tag"/>
1385  The following core rules are included by
[1806]1386  reference, as defined in <xref target="RFC5234" x:fmt="of" x:sec="B.1"/>:
[1805]1387  ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls),
1388  DIGIT (decimal 0-9), DQUOTE (double quote),
1389  HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed),
1390  OCTET (any 8-bit sequence of data), SP (space), and
1391  VCHAR (any visible US-ASCII character).
1394  Note that all rules derived from <x:ref>token</x:ref> are to
1395  be compared case-insensitively, like <x:ref>range-unit</x:ref> and
1396  <x:ref>acceptable-ranges</x:ref>.
1399  The rules below are defined in <xref target="Part1"/>:
1401<figure><artwork type="abnf2616">
1402  <x:ref>OWS</x:ref>        = &lt;OWS, defined in &whitespace;&gt;
1403  <x:ref>token</x:ref>      = &lt;token, defined in &field-components;&gt;
1406  The rules below are defined in other parts:
1408<figure><artwork type="abnf2616">
1409  <x:ref>HTTP-date</x:ref>  = &lt;HTTP-date, defined in &http-date;&gt;
1410  <x:ref>entity-tag</x:ref> = &lt;entity-tag, defined in &entity-tags;&gt;
[680]1414<?BEGININC p5-range.abnf-appendix ?>
[427]1415<section xmlns:x="" title="Collected ABNF" anchor="collected.abnf">
1417<artwork type="abnf" name="p5-range.parsed-abnf">
[1232]1418<x:ref>Accept-Ranges</x:ref> = acceptable-ranges
[1398]1420<x:ref>Content-Range</x:ref> = byte-content-range-spec / other-content-range-spec
[1663]1422<x:ref>HTTP-date</x:ref> = &lt;HTTP-date, defined in [Part2], Section 5.1&gt;
[1232]1424<x:ref>If-Range</x:ref> = entity-tag / HTTP-date
[1523]1426<x:ref>OWS</x:ref> = &lt;OWS, defined in [Part1], Section 3.2.1&gt;
[1232]1428<x:ref>Range</x:ref> = byte-ranges-specifier / other-ranges-specifier
1430<x:ref>acceptable-ranges</x:ref> = ( *( "," OWS ) range-unit *( OWS "," [ OWS
[425]1431 range-unit ] ) ) / "none"
[427]1433<x:ref>byte-content-range-spec</x:ref> = bytes-unit SP byte-range-resp-spec "/" (
[425]1434 instance-length / "*" )
[427]1435<x:ref>byte-range-resp-spec</x:ref> = ( first-byte-pos "-" last-byte-pos ) / "*"
[1663]1436<x:ref>byte-range-set</x:ref> = *( "," OWS ) ( byte-range-spec /
1437 suffix-byte-range-spec ) *( OWS "," [ OWS ( byte-range-spec /
1438 suffix-byte-range-spec ) ] )
[427]1439<x:ref>byte-range-spec</x:ref> = first-byte-pos "-" [ last-byte-pos ]
1440<x:ref>byte-ranges-specifier</x:ref> = bytes-unit "=" byte-range-set
1441<x:ref>bytes-unit</x:ref> = "bytes"
[1383]1443<x:ref>entity-tag</x:ref> = &lt;entity-tag, defined in [Part4], Section 2.3&gt;
1445<x:ref>first-byte-pos</x:ref> = 1*DIGIT
1447<x:ref>instance-length</x:ref> = 1*DIGIT
1449<x:ref>last-byte-pos</x:ref> = 1*DIGIT
1451<x:ref>other-content-range-spec</x:ref> = other-range-unit SP other-range-resp-spec
1452<x:ref>other-range-resp-spec</x:ref> = *CHAR
[638]1453<x:ref>other-range-set</x:ref> = 1*CHAR
[427]1454<x:ref>other-range-unit</x:ref> = token
[638]1455<x:ref>other-ranges-specifier</x:ref> = other-range-unit "=" other-range-set
1457<x:ref>range-unit</x:ref> = bytes-unit / other-range-unit
1459<x:ref>suffix-byte-range-spec</x:ref> = "-" suffix-length
1460<x:ref>suffix-length</x:ref> = 1*DIGIT
[1523]1462<x:ref>token</x:ref> = &lt;token, defined in [Part1], Section 3.2.4&gt;
[680]1466<?ENDINC p5-range.abnf-appendix ?>
[252]1469<section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log">
[1804]1471  Changes up to the first Working Group Last Call draft are summarized
1472  in <eref target=""/>.
[1592]1475<section title="Since draft-ietf-httpbis-p5-range-19" anchor="changes.since.19">
[1663]1477  Closed issues:
1478  <list style="symbols">
1479    <t>
1480      <eref target=""/>:
1481      "ABNF list expansion code problem"
1482    </t>
[1682]1483    <t>
1484      <eref target=""/>:
1485      "ABNF requirements for recipients"
1486    </t>
[1748]1487    <t>
1488      <eref target=""/>:
1489      "reserve 'none' as byte range unit"
1490    </t>
[1760]1491    <t>
1492      <eref target=""/>:
1493      "note introduction of new IANA registries as normative changes"
1494    </t>
[1767]1495    <t>
1496      <eref target=""/>:
1497      "range units vs leading zeroes vs size"
1498    </t>
[1663]1499  </list>
[1807]1503<section title="Since draft-ietf-httpbis-p5-range-20" anchor="changes.since.20">
1505  None yet.
Note: See TracBrowser for help on using the repository browser.