<metaname="dct.abstract"content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests.">

<metaname="description"content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests.">

<p>Discussion of this draft takes place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org), which is archived at &lt;<ahref="http://lists.w3.org/Archives/Public/ietf-http-wg/">http://lists.w3.org/Archives/Public/ietf-http-wg/</a>&gt;.

<p>The current issues list is at &lt;<ahref="http://tools.ietf.org/wg/httpbis/trac/report/3">http://tools.ietf.org/wg/httpbis/trac/report/3</a>&gt; and related documents (including fancy diffs) can be found at &lt;<ahref="http://tools.ietf.org/wg/httpbis/">http://tools.ietf.org/wg/httpbis/</a>&gt;.

<p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<ahref="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights

uses range units in the <ahref="#range.retrieval.requests"class="smpl">Range</a> (<ahref="#header.range"id="rfc.xref.header.range.1"title="Range">Section&nbsp;5.4</a>) and <ahref="#header.content-range"class="smpl">Content-Range</a> (<ahref="#header.content-range"id="rfc.xref.header.content-range.1"title="Content-Range">Section&nbsp;5.2</a>) header fields. A representation can be broken down into subranges according to various structural units.

<pid="rfc.section.2.p.4">If a range unit is not understood in a request, a server <emclass="bcp14">MUST</em> ignore the whole <ahref="#range.retrieval.requests"class="smpl">Range</a> header field (<ahref="#header.range"id="rfc.xref.header.range.2"title="Range">Section&nbsp;5.4</a>). If a range unit is not understood in a response, an intermediary <emclass="bcp14">SHOULD</em> pass the response to the client; a client <emclass="bcp14">MUST</em> fail.

<pid="rfc.section.2.1.p.3">Values to be added to this name space require IETF Review (see <ahref="#RFC5226"id="rfc.xref.RFC5226.1"><citetitle="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <ahref="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>).

<pid="rfc.section.3.1.p.1">The <dfn>206 (Partial Content)</dfn> status code indicates that the server has fulfilled the partial GET request for the resource. The request <emclass="bcp14">MUST</em> have included a <ahref="#range.retrieval.requests"class="smpl">Range</a> header field (<ahref="#header.range"id="rfc.xref.header.range.3"title="Range">Section&nbsp;5.4</a>) indicating the desired range, and <emclass="bcp14">MAY</em> have included an <ahref="#header.if-range"class="smpl">If-Range</a> header field (<ahref="#header.if-range"id="rfc.xref.header.if-range.1"title="If-Range">Section&nbsp;5.3</a>) to make the request conditional.

<li>Either a <ahref="#header.content-range"class="smpl">Content-Range</a> header field (<ahref="#header.content-range"id="rfc.xref.header.content-range.2"title="Content-Range">Section&nbsp;5.2</a>) indicating the range included with this response, or a multipart/byteranges <ahref="p2-semantics.html#header.content-type"class="smpl">Content-Type</a> including Content-Range fields for each part. If a <ahref="p1-messaging.html#header.content-length"class="smpl">Content-Length</a> header field is present in the response, its value <emclass="bcp14">MUST</em> match the actual number of octets transmitted in the message body.

<li><ahref="p6-cache.html#header.cache-control"class="smpl">Cache-Control</a>, <ahref="p4-conditional.html#header.etag"class="smpl">ETag</a>, <ahref="p6-cache.html#header.expires"class="smpl">Expires</a>, <ahref="p2-semantics.html#header.content-location"class="smpl">Content-Location</a> and/or <ahref="p2-semantics.html#header.vary"class="smpl">Vary</a>, if the header field would have been sent in a <ahref="p2-semantics.html#status.200"class="smpl">200 (OK)</a> response to the same request

<pid="rfc.section.3.1.p.3">If a 206 is generated in response to a request with an <ahref="#header.if-range"class="smpl">If-Range</a> header field, the sender <emclass="bcp14">SHOULD NOT</em> generate other representation header fields beyond those described above. Otherwise, the sender <emclass="bcp14">MUST</em> generate all of the same representation header fields that would have been sent in a <ahref="p2-semantics.html#status.200"class="smpl">200 (OK)</a> response to the same request.

<pid="rfc.section.3.2.p.1">The <dfn>416 (Requested Range Not Satisfiable)</dfn> status code indicates that none of the ranges-specifier values in the request's <ahref="#range.retrieval.requests"class="smpl">Range</a> header field (<ahref="#header.range"id="rfc.xref.header.range.4"title="Range">Section&nbsp;5.4</a>) overlap the current extent of the selected resource and the request did not include an <ahref="#header.if-range"class="smpl">If-Range</a> header field (<ahref="#header.if-range"id="rfc.xref.header.if-range.2"title="If-Range">Section&nbsp;5.3</a>). (For byte-ranges, this means that the first-byte-pos of all of the byte-range-spec values were greater than the current

<pid="rfc.section.3.2.p.2">When this status code is sent in response to a byte-range request, the sender <emclass="bcp14">SHOULD</em> generate a <ahref="#header.content-range"class="smpl">Content-Range</a> header field specifying the current length of the selected representation (see <ahref="#header.content-range"id="rfc.xref.header.content-range.3"title="Content-Range">Section&nbsp;5.2</a>).

Range Not Satisfiable)</a> response instead of a <ahref="p2-semantics.html#status.200"class="smpl">200 (OK)</a> response for an unsatisfiable <ahref="#range.retrieval.requests"class="smpl">Range</a> header field, since not all servers implement this header field.

a request for a set of ranges that overlap without any holes), this content is transmitted with a <ahref="#header.content-range"class="smpl">Content-Range</a> header field, and a <ahref="p1-messaging.html#header.content-length"class="smpl">Content-Length</a> header field showing the number of bytes actually transferred. For example,

<pid="rfc.section.4.1.p.5">A response to a request for a single range <emclass="bcp14">MUST NOT</em> be sent using the multipart/byteranges media type. A response to a request for multiple ranges, whose result is a single range, <emclass="bcp14">MAY</em> be sent as a multipart/byteranges media type with one part. A client that cannot decode a multipart/byteranges message <emclass="bcp14">MUST NOT</em> ask for multiple ranges in a single request.

defined to be either an entity-tag that is not marked as weak (<ahref="p4-conditional.html#header.etag"title="ETag">Section 2.3</a> of <ahref="#Part4"id="rfc.xref.Part4.1"><citetitle="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>) or, if no entity-tag is provided, a <ahref="p4-conditional.html#header.last-modified"class="smpl">Last-Modified</a> value that is strong in the sense defined by <ahref="p4-conditional.html#lastmod.comparison"title="Comparison">Section 2.2.2</a> of <ahref="#Part4"id="rfc.xref.Part4.2"><citetitle="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>.

<pid="rfc.section.4.2.p.2">When a client receives an incomplete <ahref="p2-semantics.html#status.200"class="smpl">200 (OK)</a> response or a <ahref="#status.206"class="smpl">206 (Partial Content)</a> response, and already has one or more partial responses for the same method and effective request URI that have the same strong

validator as present in the new response, the recipient <emclass="bcp14">MAY</em> combine some or all of those responses into a set of continuous ranges. A client <emclass="bcp14">MUST NOT</em> combine responses that differ in the strong validator or that do not have a strong validator.

<pid="rfc.section.4.2.p.3">If the new response is an incomplete <ahref="p2-semantics.html#status.200"class="smpl">200 (OK)</a> response, then the header fields of that new response are used for any combined response and replace those of the matching

<pid="rfc.section.4.2.p.4">If the new response is a <ahref="#status.206"class="smpl">206 (Partial Content)</a> response and at least one of the matching stored responses is a <ahref="p2-semantics.html#status.200"class="smpl">200 (OK)</a>, then the combined response header fields consist of the most recent 200 response's header fields. If all of the matching

fields for the combined response, except that the client <emclass="bcp14">MUST</em> use other header fields provided in the new response, aside from <ahref="#header.content-range"class="smpl">Content-Range</a>, to replace all instances of the corresponding header fields in the stored response.

responses. If the union consists of the entire range of the representation, then the client <emclass="bcp14">MUST</em> record the combined response as if it were a complete <ahref="p2-semantics.html#status.200"class="smpl">200 (OK)</a> response, including a <ahref="p1-messaging.html#header.content-length"class="smpl">Content-Length</a> header field that reflects the complete length. Otherwise, the client <emclass="bcp14">MUST</em> record the set of continuous ranges as one of the following: an incomplete <ahref="p2-semantics.html#status.200"class="smpl">200 (OK)</a> response if the combined response is a prefix of the representation, a single <ahref="#status.206"class="smpl">206 (Partial Content)</a> response containing a multipart/byteranges body, or multiple <ahref="#status.206"class="smpl">206 (Partial Content)</a> responses, each with one continuous range that is indicated by a <ahref="#header.content-range"class="smpl">Content-Range</a> header field.

</pre><pid="rfc.section.5.1.p.5">but are not required to do so. Clients <emclass="bcp14">MAY</em> generate range requests without having received this header field for the resource involved. Range units are defined in <ahref="#range.units"title="Range Units">Section&nbsp;2</a>.

</pre><pid="rfc.section.5.2.p.4">The header field <emclass="bcp14">SHOULD</em> indicate the total length of the full representation, unless this length is unknown or difficult to determine. The asterisk

<pid="rfc.section.5.2.p.5">Unlike byte-ranges-specifier values (see <ahref="#byte.ranges"title="Byte Ranges">Section&nbsp;5.4.1</a>), a byte-range-resp-spec <emclass="bcp14">MUST</em> only specify one range, and <emclass="bcp14">MUST</em> contain absolute byte positions for both the first and last byte of the range.

whose instance-length value is less than or equal to its last-byte-pos value, is invalid. The recipient of an invalid byte-content-range-spec <emclass="bcp14">MUST</em> ignore it and any content transferred along with it.

attack), the server <emclass="bcp14">SHOULD</em> treat the request as if the invalid <ahref="#range.retrieval.requests"class="smpl">Range</a> header field did not exist. (Normally, this means send a <ahref="p2-semantics.html#status.200"class="smpl">200 (OK)</a> response containing the full representation).

could use the <ahref="#range.retrieval.requests"class="smpl">Range</a> header field with a conditional GET (using either or both of <ahref="p4-conditional.html#header.if-unmodified-since"class="smpl">If-Unmodified-Since</a> and <ahref="p4-conditional.html#header.if-match"class="smpl">If-Match</a>.) However, if the condition fails because the representation has been modified, the client would then have to make a second

</pre><pid="rfc.section.5.3.p.4">Clients <emclass="bcp14">MUST NOT</em> use an entity-tag marked as weak in an If-Range field value and <emclass="bcp14">MUST NOT</em> use a <ahref="p4-conditional.html#header.last-modified"class="smpl">Last-Modified</a> date in an If-Range field value unless it has no entity-tag for the representation and the Last-Modified date it does have

for the representation is strong in the sense defined by <ahref="p4-conditional.html#lastmod.comparison"title="Comparison">Section 2.2.2</a> of <ahref="#Part4"id="rfc.xref.Part4.3"><citetitle="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>.

<pid="rfc.section.5.3.p.5">A server that evaluates a conditional range request that is applicable to one of its representations <emclass="bcp14">MUST</em> evaluate the condition as false if the entity-tag used as a validator is marked as weak or, when an HTTP-date is used as the

validator, if the date value is not strong in the sense defined by <ahref="p4-conditional.html#lastmod.comparison"title="Comparison">Section 2.2.2</a> of <ahref="#Part4"id="rfc.xref.Part4.4"><citetitle="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>. (A server can distinguish between a valid HTTP-date and any form of entity-tag by examining the first two characters.)

<pid="rfc.section.5.3.p.6">The If-Range header field <emclass="bcp14">SHOULD</em> only be sent by clients together with a Range header field. The If-Range header field <emclass="bcp14">MUST</em> be ignored if it is received in a request that does not include a Range header field. The If-Range header field <emclass="bcp14">MUST</em> be ignored by a server that does not support the sub-range operation.

resource, then the server <emclass="bcp14">SHOULD</em> send the specified sub-range of the representation using a <ahref="#status.206"class="smpl">206 (Partial Content)</a> response. If the validator does not match, then the server <emclass="bcp14">SHOULD</em> send the entire representation using a <ahref="p2-semantics.html#status.200"class="smpl">200 (OK)</a> response.

<pid="rfc.section.5.4.1.p.6">If the last-byte-pos value is present, it <emclass="bcp14">MUST</em> be greater than or equal to the first-byte-pos in that byte-range-spec, or the byte-range-spec is syntactically invalid. The

is satisfiable. Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set is unsatisfiable, the server <emclass="bcp14">SHOULD</em> send a response with a <ahref="#status.416"class="smpl">416 (Requested Range Not Satisfiable)</a> status code. Otherwise, the server <emclass="bcp14">SHOULD</em> send a response with a <ahref="#status.206"class="smpl">206 (Partial Content)</a> status code containing the satisfiable ranges of the representation.

<pid="rfc.section.5.4.1.p.12">In the byte range syntax, <ahref="#rule.ranges-specifier"class="smpl">first-byte-pos</a>, <ahref="#rule.ranges-specifier"class="smpl">last-byte-pos</a>, and <ahref="#rule.ranges-specifier"class="smpl">suffix-length</a> are expressed as decimal number of octets. Since there is no predefined limit to the length of an HTTP payload, recipients <emclass="bcp14">SHOULD</em> anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows.

<li>The presence of a Range header field in a conditional GET (a request using one or both of <ahref="p4-conditional.html#header.if-modified-since"class="smpl">If-Modified-Since</a> and <ahref="p4-conditional.html#header.if-none-match"class="smpl">If-None-Match</a>, or one or both of <ahref="p4-conditional.html#header.if-unmodified-since"class="smpl">If-Unmodified-Since</a> and <ahref="p4-conditional.html#header.if-match"class="smpl">If-Match</a>) modifies what is sent if the GET is otherwise successful and the condition is true. It does not affect the <ahref="p4-conditional.html#status.304"class="smpl">304 (Not Modified)</a> response sent if the conditional is false.

<pid="rfc.section.5.4.2.p.5">In some cases, it might be more appropriate to use the If-Range header field (see <ahref="#header.if-range"id="rfc.xref.header.if-range.3"title="If-Range">Section&nbsp;5.3</a>) in addition to the Range header field.

<pid="rfc.section.6.1.p.1">The HTTP Status Code Registry located at &lt;<ahref="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>&gt; shall be updated with the registrations below:

<pid="rfc.section.6.3.p.2">The HTTP Range Specifier Registry shall be created at &lt;<ahref="http://www.iana.org/assignments/http-range-specifiers">http://www.iana.org/assignments/http-range-specifiers</a>&gt; and be populated with the registrations below:

<pid="rfc.section.A.p.1">When an HTTP <ahref="#status.206"class="smpl">206 (Partial Content)</a> response message includes the content of multiple ranges (a response to a request for multiple non-overlapping ranges), these

are transmitted as a multipart message body (<ahref="#RFC2046"id="rfc.xref.RFC2046.1"><citetitle="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, <ahref="http://tools.ietf.org/html/rfc2046#section-5.1">Section 5.1</a>). The media type for this purpose is called "multipart/byteranges". The following is to be registered with IANA <ahref="#BCP13"id="rfc.xref.BCP13.1"><citetitle="Media Type Specifications and Registration Procedures">[BCP13]</cite></a>.

<pid="rfc.section.A.p.2">The multipart/byteranges media type includes one or more parts, each with its own <ahref="p2-semantics.html#header.content-type"class="smpl">Content-Type</a> and <ahref="#header.content-range"class="smpl">Content-Range</a> fields. The required boundary parameter specifies the boundary string used to separate each body-part.

<li>A number of clients and servers were coded to an early draft of the byteranges specification to use a media type of multipart/x-byteranges<spanid="rfc.iref.m.3"></span><spanid="rfc.iref.m.4"></span>, which is almost, but not quite compatible with the version documented in HTTP/1.1.

<pid="rfc.section.B.p.2">The Content-Range header field only has meaning when the status code explicitly defines its use. (<ahref="#header.content-range"id="rfc.xref.header.content-range.5"title="Content-Range">Section&nbsp;5.2</a>)

<pid="rfc.section.C.p.2">Note that all rules derived from <ahref="#imported.abnf"class="smpl">token</a> are to be compared case-insensitively, like <ahref="#range.units"class="smpl">range-unit</a> and <ahref="#header.accept-ranges"class="smpl">acceptable-ranges</a>.

<pid="rfc.section.E.p.1">Changes up to the first Working Group Last Call draft are summarized in &lt;<ahref="http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-19#appendix-D">http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-19#appendix-D</a>&gt;.