Source: https://trac.ietf.org/trac/httpbis/browser/draft-ietf-httpbis/latest/p5-range.html?rev=2157
Timestamp: 2019-09-17 12:14:33
Document Index: 370117201

Matched Legal Cases: ['art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art6', 'art6', 'art6', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1']

source: draft-ietf-httpbis/latest/p5-range.html @ 2157
Last change on this file since 2157 was 2157, checked in by fielding@…, 7 years ago
content: "Expires July 28, 2013";
<meta name="dct.issued" scheme="ISO8601" content="2013-01-24">
<td class="left">Expires: July 28, 2013</td>
<td class="right">January 24, 2013</td>
<p>This Internet-Draft will expire on July 28, 2013.</p>
<p id="rfc.section.1.p.2">This document defines HTTP/1.1 range requests, partial responses, and the multipart/byteranges media type, obsoleting those
parts previously defined in <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. Range requests are an <em class="bcp14">OPTIONAL</em> feature of HTTP, designed so that recipients not implementing this feature (or not supporting it for the target resource)
</pre><h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="byte.ranges" href="#byte.ranges">Byte Ranges</a></h2>
<p id="rfc.section.2.1.p.3"> A byte range operation <em class="bcp14">MAY</em> specify a single range of bytes, or a set of ranges within a single representation.
</pre><p id="rfc.section.2.1.p.11">If the selected representation is shorter than the specified <a href="#rule.ranges-specifier" class="smpl">suffix-length</a>, the entire representation is used. For example (assuming a representation of length 10000):
<p id="rfc.section.2.1.p.12">If a valid <a href="#rule.ranges-specifier" class="smpl">byte-range-set</a> includes at least one <a href="#rule.ranges-specifier" class="smpl">byte-range-spec</a> with a <a href="#rule.ranges-specifier" class="smpl">first-byte-pos</a> that is less than the current length of the representation, or at least one <a href="#rule.ranges-specifier" class="smpl">suffix-byte-range-spec</a> with a non-zero <a href="#rule.ranges-specifier" class="smpl">suffix-length</a>, then the <a href="#rule.ranges-specifier" class="smpl">byte-range-set</a> is satisfiable. Otherwise, the <a href="#rule.ranges-specifier" class="smpl">byte-range-set</a> is unsatisfiable.
<p id="rfc.section.2.1.p.13">In the byte range syntax, <a href="#rule.ranges-specifier" class="smpl">first-byte-pos</a>, <a href="#rule.ranges-specifier" class="smpl">last-byte-pos</a>, and <a href="#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 a payload, recipients ought
to anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows.
<h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="range.units.other" href="#range.units.other">Other Range Units</a></h2>
</pre><div id="rfc.iref.a.1"></div>
<h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="header.accept-ranges" href="#header.accept-ranges">Accept-Ranges</a></h2>
</pre><p id="rfc.section.2.3.p.3">Origin servers that support byte-range requests <em class="bcp14">MAY</em> send
</pre><p id="rfc.section.2.3.p.5">but are not required to do so. Clients <em class="bcp14">MAY</em> generate range requests without having received this header field for the resource involved. Range units are defined in <a href="#range.units" title="Range Units">Section&nbsp;2</a>.
<p id="rfc.section.2.3.p.6">Servers that do not support any kind of range request for the target resource resource <em class="bcp14">MAY</em> send
<h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="range.requests" href="#range.requests">Range Requests</a></h1>
<h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="header.range" href="#header.range">Range</a></h2>
<a href="#header.range" class="smpl">other-range-set</a> = 1*<a href="#imported.abnf" class="smpl">CHAR</a>
<p id="rfc.section.3.1.p.4">An origin server <em class="bcp14">MUST</em> ignore a Range header field that contains a range unit it does not understand. A proxy <em class="bcp14">MAY</em> either discard a Range header field that contains a range unit it does not understand or pass it to the next inbound server
when forwarding the request.
<p id="rfc.section.3.1.p.5">A server that supports range requests ought to ignore or reject a <a href="#header.range" class="smpl">Range</a> header field that consists of more than two overlapping ranges, or a set of many small ranges that are not listed in ascending
<h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="header.if-range" href="#header.if-range">If-Range</a></h2>
could use the <a href="#header.range" class="smpl">Range</a> header field with a conditional GET (using either or both of <a href="p4-conditional.html#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> and <a href="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><p id="rfc.section.3.2.p.4">Clients <em class="bcp14">MUST NOT</em> use an entity-tag marked as weak in an If-Range field value and <em class="bcp14">MUST NOT</em> use a <a href="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 <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>.
<p id="rfc.section.3.2.p.5">A server that evaluates a conditional range request that is applicable to one of its representations <em class="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 <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="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.)
<p id="rfc.section.3.2.p.6">A client <em class="bcp14">MUST NOT</em> generate an If-Range header field in a request that does not contain a <a href="#header.range" class="smpl">Range</a> header field. A server <em class="bcp14">MUST</em> ignore an If-Range header field received in a request that does not contain a <a href="#header.range" class="smpl">Range</a> header field. An origin server <em class="bcp14">MUST</em> ignore an If-Range header field received in a request for a target resource that does not support Range requests.
resource, then the server <em class="bcp14">SHOULD</em> process the Range header field as requested. If the validator does not match, then the server <em class="bcp14">MUST</em> ignore the <a href="#header.range" class="smpl">Range</a> header field.
or more parts of the selected representation that correspond to the satisfiable ranges found in the requests's <a href="#header.range" class="smpl">Range</a> header field (<a href="#header.range" id="rfc.xref.header.range.2" title="Range">Section&nbsp;3.1</a>).
</pre><p id="rfc.section.4.1.p.4">If multiple parts are being transferred, the server generating the 206 response <em class="bcp14">MUST</em> generate a "multipart/byteranges" payload, as defined in <a href="#internet.media.type.multipart.byteranges" title="Internet Media Type multipart/byteranges">Appendix&nbsp;A</a>, and send a <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> header field containing the multipart/byteranges media type and its required boundary parameter. Within the header area of
each body part in the multipart payload, the server <em class="bcp14">MUST</em> generate a <a href="#header.content-range" class="smpl">Content-Range</a> header field corresponding to the range being enclosed in that body part. If the selected representation would have had a <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> header field in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response, the server <em class="bcp14">SHOULD</em> generate that same <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> field in the header area of each body part. For example:
</pre><p id="rfc.section.4.1.p.6">When multiple ranges are requested, a server <em class="bcp14">MAY</em> coalesce any of the ranges that overlap or that are separated by a gap that is smaller than the overhead of sending multiple
<p id="rfc.section.4.1.p.7">A server <em class="bcp14">MUST NOT</em> generate a multipart response to a request for a single range, since a client that does not request multiple parts might not
response <em class="bcp14">MUST NOT</em> ask for multiple ranges in a single request.
<p id="rfc.section.4.1.p.8">When a multipart response payload is generated, the server <em class="bcp14">SHOULD</em> send the parts in the same order that the corresponding byte-range-spec appeared in the received <a href="#header.range" class="smpl">Range</a> header field, excluding those ranges that were deemed unsatisfiable or that were coalesced into other ranges. A client that
<p id="rfc.section.4.1.p.9">When a 206 response is generated, the server <em class="bcp14">MUST</em> generate the following header fields, in addition to those described above, if the field would have been sent in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request: <a href="p2-semantics.html#header.date" class="smpl">Date</a>, <a href="p6-cache.html#header.cache-control" class="smpl">Cache-Control</a>, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a>, <a href="p6-cache.html#header.expires" class="smpl">Expires</a>, <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a>, and <a href="p2-semantics.html#header.vary" class="smpl">Vary</a>.
<p id="rfc.section.4.1.p.10">If a 206 is generated in response to a request with an <a href="#header.if-range" class="smpl">If-Range</a> header field, the sender <em class="bcp14">SHOULD NOT</em> generate other representation header fields beyond those described above because the client is understood to already have
<p id="rfc.section.4.1.p.11">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to determine freshness for 206 responses.
<p id="rfc.section.4.2.p.6">A server generating a <a href="#status.206" class="smpl">206 (Partial Content)</a> response to a byte range request <em class="bcp14">MUST</em> send, in each body part of a multipart response or in the header block of a single part response, a Content-Range header field
<p id="rfc.section.4.4.p.1">The <dfn>416 (Range Not Satisfiable)</dfn> status code indicates that none of the ranges-specifier values in the request's <a href="#header.range" class="smpl">Range</a> header field (<a href="#header.range" id="rfc.xref.header.range.3" title="Range">Section&nbsp;3.1</a>) overlap the current extent of the selected resource and the request did not include an <a href="#header.if-range" class="smpl">If-Range</a> header field (<a href="#header.if-range" id="rfc.xref.header.if-range.2" title="If-Range">Section&nbsp;3.2</a>). (For byte-ranges, this means that the first-byte-pos of all of the byte-range-spec values were greater than the current
<p id="rfc.section.4.4.p.2">When this status code is sent in response to a byte-range request, the sender <em class="bcp14">SHOULD</em> generate a <a href="#header.content-range" class="smpl">Content-Range</a> header field specifying the current length of the selected representation (see <a href="#header.content-range" id="rfc.xref.header.content-range.2" title="Content-Range">Section&nbsp;4.2</a>).
The registry is maintained at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt;.
<h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;<a id="range.unit.registry.procedure" href="#range.unit.registry.procedure">Procedure</a></h3>
<h3 id="rfc.section.5.1.2"><a href="#rfc.section.5.1.2">5.1.2</a>&nbsp;<a id="range.unit.registration" href="#range.unit.registration">Registrations</a></h3>
<td class="left"> <a href="#header.if-range" id="rfc.xref.header.if-range.3" title="If-Range">Section&nbsp;3.2</a>
<h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="overlapping.ranges" href="#overlapping.ranges">Denial of Service Attacks using Range</a></h2>
<p id="rfc.section.7.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
<p id="rfc.section.A.p.1">When a <a href="#status.206" class="smpl">206 (Partial Content)</a> response message includes the content of multiple ranges, they are transmitted as body parts in a multipart message body (<a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, <a href="http://tools.ietf.org/html/rfc2046#section-5.1">Section 5.1</a>) with the media type of "multipart/byteranges". The following definition is to be registered with IANA <a href="#BCP13" id="rfc.xref.BCP13.1"><cite title="Media Type Specifications and Registration Procedures">[BCP13]</cite></a>.
<p id="rfc.section.A.p.4">Implementation Notes: </p>
<li>A number of clients and servers were coded to an early draft of the byteranges specification that used a media type of multipart/x-byteranges<span id="rfc.iref.m.3"></span><span id="rfc.iref.m.4"></span>, which is almost (but not quite) compatible with this type.
<p id="rfc.section.A.p.5">Despite the name, the "multipart/byteranges" media type is not limited to byte ranges. The following example uses an "exampleunit"
</pre> <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1>
<p id="rfc.section.B.p.2">The Content-Range header field only has meaning when the status code explicitly defines its use. (<a href="#header.content-range" id="rfc.xref.header.content-range.4" title="Content-Range">Section&nbsp;4.2</a>)
<p id="rfc.section.B.p.5">This specification introduces a Range Unit Registry. (<a href="#range.unit.registry" title="Range Unit Registry">Section&nbsp;5.1</a>)
<div id="rfc.figure.u.31"></div> <pre class="inline"><a href="#header.accept-ranges" class="smpl">Accept-Ranges</a> = acceptable-ranges
<a href="#header.range" class="smpl">other-range-set</a> = 1*CHAR
<li><em>BCP13</em>&nbsp;&nbsp;<a href="#BCP13"><b>8.2</b></a>, <a href="#rfc.xref.BCP13.1">A</a></li>
<li>If-Range header field&nbsp;&nbsp;<a href="#rfc.xref.header.if-range.1">3.1</a>, <a href="#rfc.iref.i.1"><b>3.2</b></a>, <a href="#rfc.xref.header.if-range.2">4.4</a>, <a href="#rfc.xref.header.if-range.3">5.3</a></li>
<li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">6</a>, <a href="#rfc.xref.Part1.4">7</a>, <a href="#Part1"><b>8.1</b></a>, <a href="#rfc.xref.Part1.5">C</a>, <a href="#rfc.xref.Part1.6">C</a>, <a href="#rfc.xref.Part1.7">C</a><ul>
<li><em>Section 9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.4">7</a></li>
<li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">1</a>, <a href="#RFC2616"><b>8.2</b></a></li>