<metaname="dct.abstract"content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 5 defines range-specific 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, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests.">

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 Range (<ahref="#header.range"id="rfc.xref.header.range.1"title="Range">Section&nbsp;5.4</a>) and Content-Range (<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 Range 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 are subject to IETF review (<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 server has fulfilled the partial GET request for the resource. The request <emclass="bcp14">MUST</em> have included a Range 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 If-Range 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 Content-Range 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 Content-Type including Content-Range fields

<pid="rfc.section.3.1.p.3">If the 206 response is the result of an If-Range request, the response <emclass="bcp14">SHOULD NOT</em> include other representation header fields. Otherwise, the response <emclass="bcp14">MUST</em> include all of the representation header fields that would have been returned with a 200 (OK) response to the same request.

<pid="rfc.section.3.1.p.5">A cache that does not support the Range and Content-Range header fields <emclass="bcp14">MUST NOT</em> cache 206 (Partial Content) responses. Furthermore, if a response uses a range unit that is not understood by the cache, then

<pid="rfc.section.3.2.p.1">A server <emclass="bcp14">SHOULD</em> return a response with this status code if a request included a Range request-header field (<ahref="#header.range"id="rfc.xref.header.range.4"title="Range">Section&nbsp;5.4</a>), and none of the ranges-specifier values in this field overlap the current extent of the selected resource, and the request

did not include an If-Range request-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 returned for a byte-range request, the response <emclass="bcp14">SHOULD</em> include a Content-Range header field specifying the current length of the representation (see <ahref="#header.content-range"id="rfc.xref.header.content-range.3"title="Content-Range">Section&nbsp;5.2</a>). This response <emclass="bcp14">MUST NOT</em> use the multipart/byteranges content-type.

<pid="rfc.section.4.p.3">If either requirement is not met, the cache <emclass="bcp14">MUST</em> use only the most recent partial response (based on the Date values transmitted with every response, and using the incoming

</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.

<pid="rfc.section.5.2.p.7">In the case of a byte range request: A server sending a response with status code 416 (Requested range not satisfiable) <emclass="bcp14">SHOULD</em> include a Content-Range field with a byte-range-resp-spec of "*". The instance-length specifies the current length of the

<pid="rfc.section.5.2.p.12">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.

<pid="rfc.section.5.2.p.14">If the server ignores a byte-range-spec because it is syntactically invalid, the server <emclass="bcp14">SHOULD</em> treat the request as if the invalid Range header field did not exist. (Normally, this means return a 200 response containing

</pre><pid="rfc.section.5.3.p.4">If the client has no entity-tag for a representation, but does have a Last-Modified date, it <emclass="bcp14">MAY</em> use that date in an If-Range header field. (The server can distinguish between a valid HTTP-date and any form of entity-tag

by examining no more than two characters.) The If-Range header field <emclass="bcp14">SHOULD</em> only be used together with a Range header field, and <emclass="bcp14">MUST</em> be ignored if the request does not include a Range header field, or if the server does not support the sub-range operation.

<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> return a response with a 416 (Requested range not satisfiable) status code. Otherwise, the server <emclass="bcp14">SHOULD</em> return a response with a 206 (Partial Content) status code containing the satisfiable ranges of the representation.

<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.7.p.1">No additional security considerations have been identified beyond those applicable to HTTP in general <ahref="#Part1"id="rfc.xref.Part1.6"><citetitle="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.

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="#RFC4288"id="rfc.xref.RFC4288.1"><citetitle="Media Type Specifications and Registration Procedures">[RFC4288]</cite></a>.

<li>A number of browsers 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.1.p.2">Clarify that multipart/byteranges can consist of a single part. (<ahref="#internet.media.type.multipart.byteranges"title="Internet Media Type multipart/byteranges">Appendix&nbsp;A</a>)

<pid="rfc.section.D.4.p.1">Ongoing work on IANA Message Header Field Registration (&lt;<ahref="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>&gt;):