Changeset 2157 for draft-ietf-httpbis


Ignore:
Timestamp:
24/01/13 12:02:20 (10 years ago)
Author:
fielding@…
Message:

Address range flooding security issue (#175 and #311) by direct
requirements and recommendations.

Actually require Content-Range and Content-Type (when appropriate) inside
multipart/byteranges body parts instead of assuming that the reader will
read between the lines of the MIME registration template.

Simplify description of required headers in 206 responses.

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p5-range.html

    r2153 r2157  
    449449  }
    450450  @bottom-center {
    451        content: "Expires July 27, 2013";
     451       content: "Expires July 28, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    492492      <meta name="dct.creator" content="Reschke, J. F.">
    493493      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
    494       <meta name="dct.issued" scheme="ISO8601" content="2013-01-23">
     494      <meta name="dct.issued" scheme="ISO8601" content="2013-01-24">
    495495      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    496496      <meta name="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.">
    … …  
    518518            </tr>
    519519            <tr>
    520                <td class="left">Expires: July 27, 2013</td>
     520               <td class="left">Expires: July 28, 2013</td>
    521521               <td class="right">J. Reschke, Editor</td>
    522522            </tr>
    … …  
    527527            <tr>
    528528               <td class="left"></td>
    529                <td class="right">January 23, 2013</td>
     529               <td class="right">January 24, 2013</td>
    530530            </tr>
    531531         </tbody>
    … …  
    552552         in progress”.
    553553      </p>
    554       <p>This Internet-Draft will expire on July 27, 2013.</p>
     554      <p>This Internet-Draft will expire on July 28, 2013.</p>
    555555      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    556556      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    604604         </li>
    605605         <li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul>
    606                <li><a href="#rfc.section.6.1">6.1</a>&nbsp;&nbsp;&nbsp;<a href="#overlapping.ranges">Overlapping Ranges</a></li>
     606               <li><a href="#rfc.section.6.1">6.1</a>&nbsp;&nbsp;&nbsp;<a href="#overlapping.ranges">Denial of Service Attacks using Range</a></li>
    607607            </ul>
    608608         </li>
    … …  
    745745         when forwarding the request.
    746746      </p>
    747       <p id="rfc.section.3.1.p.5">The Range header field is evaluated after evaluating the preconditions of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a> and only if the result of their evaluation is leading toward a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response. In other words, Range is ignored when a conditional GET would result in a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response.
    748       </p>
    749       <p id="rfc.section.3.1.p.6">The If-Range header field (<a href="#header.if-range" id="rfc.xref.header.if-range.1" title="If-Range">Section&nbsp;3.2</a>) can be used as a precondition to applying the Range header field.
    750       </p>
    751       <p id="rfc.section.3.1.p.7">If all of the preconditions are true, the server supports the Range header field for the target resource, and the specified
     747      <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
     748         order, since both are indications of either a broken client or a deliberate denial of service attack (<a href="#overlapping.ranges" title="Denial of Service Attacks using Range">Section&nbsp;6.1</a>). A client <em class="bcp14">SHOULD NOT</em> request multiple ranges that are inherently less efficient to process and transfer than a single range that encompasses the
     749         same data.
     750      </p>
     751      <p id="rfc.section.3.1.p.6">A client that is requesting multiple ranges <em class="bcp14">SHOULD</em> list those ranges in ascending order (the order in which they would typically be received in a complete representation) unless
     752         there is a specific need to request a later part earlier. For example, a user agent processing a large representation with
     753         an internal catalog of parts might need to request later parts first, particularly if the representation consists of pages
     754         stored in reverse order and the user agent wishes to transfer one page at a time.
     755      </p>
     756      <p id="rfc.section.3.1.p.7">The Range header field is evaluated after evaluating the preconditions of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a> and only if the result of their evaluation is leading toward a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response. In other words, Range is ignored when a conditional GET would result in a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response.
     757      </p>
     758      <p id="rfc.section.3.1.p.8">The If-Range header field (<a href="#header.if-range" id="rfc.xref.header.if-range.1" title="If-Range">Section&nbsp;3.2</a>) can be used as a precondition to applying the Range header field.
     759      </p>
     760      <p id="rfc.section.3.1.p.9">If all of the preconditions are true, the server supports the Range header field for the target resource, and the specified
    752761         range(s) are valid and satisfiable (as defined in <a href="#byte.ranges" title="Byte Ranges">Section&nbsp;2.1</a>), the server <em class="bcp14">SHOULD</em> send a <a href="#status.206" class="smpl">206 (Partial Content)</a> response with a payload containing one or more partial representations that correspond to the satisfiable ranges requested,
    753762         as defined in <a href="#range.response" title="Responses to a Range Request">Section&nbsp;4</a>.
    754763      </p>
    755       <p id="rfc.section.3.1.p.8">If all of the preconditions are true, the server supports the Range header field for the target resource, and the specified
     764      <p id="rfc.section.3.1.p.10">If all of the preconditions are true, the server supports the Range header field for the target resource, and the specified
    756765         range(s) are invalid or unsatisfiable, the server <em class="bcp14">SHOULD</em> send a <a href="#status.416" class="smpl">416 (Range Not Satisfiable)</a> response.
    757766      </p>
    … …  
    793802Content-Type: image/gif
    794803
    795 ... 26012 bytes of image data ...
    796 </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. For example:
     804... 26012 bytes of partial image data ...
     805</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
     806         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:
    797807      </p>
    798808      <div id="rfc.figure.u.18"></div><pre class="text">HTTP/1.1 206 Partial Content
    … …  
    813823...the second range
    814824--THIS_STRING_SEPARATES--
    815 </pre><p id="rfc.section.4.1.p.6">A server <em class="bcp14">MAY</em> combine requested ranges when those ranges are overlapping (see <a href="#overlapping.ranges" title="Overlapping Ranges">Section&nbsp;6.1</a>).
    816       </p>
    817       <p id="rfc.section.4.1.p.7">A response to a request for a single range <em class="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, <em class="bcp14">MAY</em> be sent as a multipart/byteranges media type with one part. A client that cannot decode a multipart/byteranges message <em class="bcp14">MUST NOT</em> ask for multiple ranges in a single request.
    818       </p>
    819       <p id="rfc.section.4.1.p.8">When a client asks for multiple ranges in one request, the server <em class="bcp14">SHOULD</em> send them in the order that they appeared in the request.
    820       </p>
    821       <p id="rfc.section.4.1.p.9">When a 206 response is generated, the sender <em class="bcp14">MUST</em> generate the following header fields:
    822       </p>
    823       <ul>
    824          <li>Either a <a href="#header.content-range" class="smpl">Content-Range</a> header field (<a href="#header.content-range" id="rfc.xref.header.content-range.2" title="Content-Range">Section&nbsp;4.2</a>) indicating the single range included with this response, or a multipart/byteranges <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> indicating that multiple ranges are enclosed as multipart body-parts.
    825          </li>
    826          <li> <a href="p2-semantics.html#header.date" class="smpl">Date</a>
    827          </li>
    828          <li> <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/or <a href="p2-semantics.html#header.vary" class="smpl">Vary</a>, if the header field would have been sent in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request
    829          </li>
    830       </ul>
    831       <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. Otherwise, the sender <em class="bcp14">MUST</em> generate all of the same representation header fields that would have been sent in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request.
     825</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
     826         parts, regardless of the order in which the corresponding byte-range-spec appeared in the received <a href="#header.range" class="smpl">Range</a> header field. Since the typical overhead between parts of a multipart/byteranges payload is around 80 bytes, depending on
     827         the selected representation's media type and the chosen boundary parameter length, it can be less efficient to transfer many
     828         small disjoint parts than it is to transfer the entire selected representation.
     829      </p>
     830      <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
     831         support multipart responses. However, a server <em class="bcp14">MAY</em> generate a multipart/byteranges payload with only a single body part if multiple ranges were requested and only one range
     832         was found to be satisfiable or only one range remained after coalescing. A client that cannot process a multipart/byteranges
     833         response <em class="bcp14">MUST NOT</em> ask for multiple ranges in a single request.
     834      </p>
     835      <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
     836         receives a multipart response <em class="bcp14">MUST</em> inspect the <a href="#header.content-range" class="smpl">Content-Range</a> header field present in each body part in order to determine which range is contained in that body part; a client cannot rely
     837         on receiving the same ranges that it requested, nor the same order that it requested.
     838      </p>
     839      <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>.
     840      </p>
     841      <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
     842         a prior response containing those header fields. Otherwise, the sender <em class="bcp14">MUST</em> generate all of the representation header fields that would have been sent in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request.
    832843      </p>
    833844      <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.
    … …  
    860871      <p id="rfc.section.4.2.p.5">A Content-Range field value with a <a href="#header.content-range" class="smpl">byte-range-resp</a> that has a <a href="#rule.ranges-specifier" class="smpl">last-byte-pos</a> value less than its <a href="#rule.ranges-specifier" class="smpl">first-byte-pos</a> value, or a <a href="#header.content-range" class="smpl">complete-length</a> value less than or equal to its <a href="#rule.ranges-specifier" class="smpl">last-byte-pos</a> value, is invalid. The recipient of an invalid <a href="#header.content-range" class="smpl">Content-Range</a>  <em class="bcp14">MUST NOT</em> attempt to recombine the received content with a stored representation.
    861872      </p>
    862       <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
     873      <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
    863874         containing a <a href="#header.content-range" class="smpl">byte-range-resp</a> value that reflects the corresponding range being sent. The following example would apply when the complete length of the
    864875         selected representation is known by the sender to be 1234 bytes:
    … …  
    915926         length of the selected representation.)
    916927      </p>
    917       <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.3" title="Content-Range">Section&nbsp;4.2</a>).
     928      <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>).
    918929      </p>
    919930      <div id="rfc.figure.u.27"></div>
    … …  
    10241035                  <td class="left">http</td>
    10251036                  <td class="left">standard</td>
    1026                   <td class="left"> <a href="#header.content-range" id="rfc.xref.header.content-range.4" title="Content-Range">Section&nbsp;4.2</a>
     1037                  <td class="left"> <a href="#header.content-range" id="rfc.xref.header.content-range.3" title="Content-Range">Section&nbsp;4.2</a>
    10271038                  </td>
    10281039               </tr>
    … …  
    10491060         range request mechanisms. More general security considerations are addressed in HTTP messaging <a href="#Part1" id="rfc.xref.Part1.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> and semantics <a href="#Part2" id="rfc.xref.Part2.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>.
    10501061      </p>
    1051       <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="overlapping.ranges" href="#overlapping.ranges">Overlapping Ranges</a></h2>
    1052       <p id="rfc.section.6.1.p.1">Range requests containing overlapping ranges can lead to a situation where the server is sending far more data than the size
    1053          of the complete resource representation.
     1062      <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>
     1063      <p id="rfc.section.6.1.p.1">Unconstrained multiple range requests are susceptible to denial of service attacks because the effort required to request
     1064         many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve
     1065         the requested data in many parts. Servers ought to ignore, coalesce, or reject egregious range requests, such as requests
     1066         for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested
     1067         out of order for no apparent reason. Multipart range requests are not designed to support random access.
    10541068      </p>
    10551069      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
    … …  
    11361150      <div id="rfc.iref.m.2"></div>
    11371151      <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;<a id="internet.media.type.multipart.byteranges" href="#internet.media.type.multipart.byteranges">Internet Media Type multipart/byteranges</a></h1>
    1138       <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>.
    1139       </p>
    1140       <p id="rfc.section.A.p.2">The multipart/byteranges media type includes one or more body-parts, each with its own <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> and <a href="#header.content-range" class="smpl">Content-Range</a> fields. The required boundary parameter specifies the boundary string used to separate each body-part.
     1152      <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>.
     1153      </p>
     1154      <p id="rfc.section.A.p.2">The multipart/byteranges media type includes one or more body parts, each with its own <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> and <a href="#header.content-range" class="smpl">Content-Range</a> fields. The required boundary parameter specifies the boundary string used to separate each body part.
    11411155      </p>
    11421156      <p id="rfc.section.A.p.3"> </p>
    … …  
    12121226      <p id="rfc.section.B.p.1">A weak validator cannot be used in a <a href="#status.206" class="smpl">206</a> response. (<a href="#status.206" id="rfc.xref.status.206.2" title="206 Partial Content">Section&nbsp;4.1</a>)
    12131227      </p>
    1214       <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.5" title="Content-Range">Section&nbsp;4.2</a>)
     1228      <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>)
    12151229      </p>
    12161230      <p id="rfc.section.B.p.3">Servers are given more leeway in how they respond to a range request, in order to mitigate abuse by malicious (or just greedy)
    … …  
    13311345            </li>
    13321346            <li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul>
    1333                   <li>Content-Range header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-range.1">2</a>, <a href="#rfc.xref.header.content-range.2">4.1</a>, <a href="#rfc.iref.c.1"><b>4.2</b></a>, <a href="#rfc.xref.header.content-range.3">4.4</a>, <a href="#rfc.xref.header.content-range.4">5.3</a>, <a href="#rfc.xref.header.content-range.5">B</a></li>
     1347                  <li>Content-Range header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-range.1">2</a>, <a href="#rfc.iref.c.1"><b>4.2</b></a>, <a href="#rfc.xref.header.content-range.2">4.4</a>, <a href="#rfc.xref.header.content-range.3">5.3</a>, <a href="#rfc.xref.header.content-range.4">B</a></li>
    13341348               </ul>
    13351349            </li>

  • draft-ietf-httpbis/latest/p5-range.xml

    r2153 r2157  
    396396</t>
    397397<t>
     398   A server that supports range requests ought to ignore or reject a
     399   <x:ref>Range</x:ref> header field that consists of more than two
     400   overlapping ranges, or a set of many small ranges that are not listed
     401   in ascending order, since both are indications of either a broken client or
     402   a deliberate denial of service attack (<xref target="overlapping.ranges"/>).
     403   A client &SHOULD-NOT; request multiple ranges that are inherently less
     404   efficient to process and transfer than a single range that encompasses the
     405   same data.
     406</t>
     407<t>
     408   A client that is requesting multiple ranges &SHOULD; list those ranges in
     409   ascending order (the order in which they would typically be received in a
     410   complete representation) unless there is a specific need to request a later
     411   part earlier. For example, a user agent processing a large representation
     412   with an internal catalog of parts might need to request later parts first,
     413   particularly if the representation consists of pages stored in reverse
     414   order and the user agent wishes to transfer one page at a time.
     415</t>
     416<t>
    398417   The Range header field is evaluated after evaluating the preconditions of
    399418   <xref target="Part4"/> and only if the result of their evaluation is
    … …  
    506525Content-Type: image/gif
    507526
    508 ... 26012 bytes of image data ...
     527... 26012 bytes of partial image data ...
    509528</artwork></figure>
    510529<t>
    … …  
    513532   in <xref target="internet.media.type.multipart.byteranges"/>, and send a
    514533   <x:ref>Content-Type</x:ref> header field containing the
    515    "multipart/byteranges" media type and its required boundary parameter.
    516    For example:
    517 </t>
    518 <figure><preamble>
    519 </preamble><artwork type="message/http; msgtype=&#34;response&#34;" x:indent-with="  ">
     534   multipart/byteranges media type and its required boundary parameter.
     535   Within the header area of each body part in the multipart payload, the
     536   server &MUST; generate a <x:ref>Content-Range</x:ref> header field
     537   corresponding to the range being enclosed in that body part.
     538   If the selected representation would have had a <x:ref>Content-Type</x:ref>
     539   header field in a <x:ref>200 (OK)</x:ref> response, the server &SHOULD;
     540   generate that same <x:ref>Content-Type</x:ref> field in the header area of
     541   each body part. For example:
     542</t>
     543<figure><artwork type="message/http; msgtype=&#34;response&#34;" x:indent-with="  ">
    520544HTTP/1.1 206 Partial Content
    521545Date: Wed, 15 Nov 1995 06:25:24 GMT
    … …  
    537561</artwork></figure>
    538562<t>
    539    A server &MAY; combine requested ranges when those ranges are overlapping
    540    (see <xref target="overlapping.ranges"/>).
    541 </t>
    542 <t>
    543    A response to a request for a single range &MUST-NOT; be sent using the
    544    multipart/byteranges media type.  A response to a request for
    545    multiple ranges, whose result is a single range, &MAY; be sent as a
    546    multipart/byteranges media type with one part. A client that cannot
    547    decode a multipart/byteranges message &MUST-NOT; ask for multiple
    548    ranges in a single request.
    549 </t>
    550 <t>
    551    When a client asks for multiple ranges in one request, the
    552    server &SHOULD; send them in the order that they appeared in the
    553    request.
    554 </t>
    555 <t>
    556    When a 206 response is generated, the sender &MUST; generate the following
    557    header fields:
    558   <list style="symbols">
    559     <t>
    560         Either a <x:ref>Content-Range</x:ref> header field
    561         (<xref target="header.content-range"/>) indicating the single range
    562         included with this response, or a multipart/byteranges
    563         <x:ref>Content-Type</x:ref> indicating that multiple ranges are
    564         enclosed as multipart body-parts.
    565     </t>
    566     <t>
    567         <x:ref>Date</x:ref>
    568     </t>
    569     <t>
    570         <x:ref>Cache-Control</x:ref>, <x:ref>ETag</x:ref>,
    571         <x:ref>Expires</x:ref>, <x:ref>Content-Location</x:ref> and/or
    572         <x:ref>Vary</x:ref>, if the header field would have been sent in a
    573         <x:ref>200 (OK)</x:ref> response to the same request
    574     </t>
    575   </list>
     563   When multiple ranges are requested, a server &MAY; coalesce any of the
     564   ranges that overlap or that are separated by a gap that is smaller than the
     565   overhead of sending multiple parts, regardless of the order in which the
     566   corresponding byte-range-spec appeared in the received <x:ref>Range</x:ref>
     567   header field. Since the typical overhead between parts of a
     568   multipart/byteranges payload is around 80 bytes, depending on the selected
     569   representation's media type and the chosen boundary parameter length, it
     570   can be less efficient to transfer many small disjoint parts than it is to
     571   transfer the entire selected representation.
     572</t>
     573<t>
     574   A server &MUST-NOT; generate a multipart response to a request for a single
     575   range, since a client that does not request multiple parts might not
     576   support multipart responses. However, a server &MAY; generate a
     577   multipart/byteranges payload with only a single body part if multiple
     578   ranges were requested and only one range was found to be satisfiable or
     579   only one range remained after coalescing.
     580   A client that cannot process a multipart/byteranges response &MUST-NOT; ask
     581   for multiple ranges in a single request.
     582</t>
     583<t>
     584   When a multipart response payload is generated, the server &SHOULD; send
     585   the parts in the same order that the corresponding byte-range-spec appeared
     586   in the received <x:ref>Range</x:ref> header field, excluding those ranges
     587   that were deemed unsatisfiable or that were coalesced into other ranges.
     588   A client that receives a multipart response &MUST; inspect the
     589   <x:ref>Content-Range</x:ref> header field present in each body part in
     590   order to determine which range is contained in that body part; a client
     591   cannot rely on receiving the same ranges that it requested, nor the same
     592   order that it requested.
     593</t>
     594<t>
     595   When a 206 response is generated, the server &MUST; generate the following
     596   header fields, in addition to those described above, if the field would
     597   have been sent in a <x:ref>200 (OK)</x:ref> response to the same request:
     598   <x:ref>Date</x:ref>, <x:ref>Cache-Control</x:ref>, <x:ref>ETag</x:ref>,
     599   <x:ref>Expires</x:ref>, <x:ref>Content-Location</x:ref>, and
     600   <x:ref>Vary</x:ref>.
    576601</t>
    577602<t>
    578603   If a 206 is generated in response to a request with an <x:ref>If-Range</x:ref>
    579604   header field, the sender &SHOULD-NOT; generate other representation header
    580    fields beyond those described above.
    581    Otherwise, the sender &MUST; generate all of the same representation header
     605   fields beyond those described above because the client is understood to
     606   already have a prior response containing those header fields.
     607   Otherwise, the sender &MUST; generate all of the representation header
    582608   fields that would have been sent in a <x:ref>200 (OK)</x:ref> response
    583609   to the same request.
    … …  
    644670<t>
    645671   A server generating a <x:ref>206 (Partial Content)</x:ref> response to a
    646    byte range request &MUST; send, in each body-part of a multipart response
     672   byte range request &MUST; send, in each body part of a multipart response
    647673   or in the header block of a single part response, a Content-Range header
    648674   field containing a <x:ref>byte-range-resp</x:ref> value that reflects the
    … …  
    937963</t>
    938964
    939 <section title="Overlapping Ranges" anchor="overlapping.ranges">
    940 <t>
    941    Range requests containing overlapping ranges can lead to a situation
    942    where the server is sending far more data than the size of the complete
    943    resource representation.
     965<section title="Denial of Service Attacks using Range" anchor="overlapping.ranges">
     966<t>
     967   Unconstrained multiple range requests are susceptible to denial of service
     968   attacks because the effort required to request many overlapping ranges of
     969   the same data is tiny compared to the time, memory, and bandwidth consumed
     970   by attempting to serve the requested data in many parts.
     971   Servers ought to ignore, coalesce, or reject egregious range requests, such
     972   as requests for more than two overlapping ranges or for many small ranges
     973   in a single set, particularly when the ranges are requested out of order
     974   for no apparent reason. Multipart range requests are not designed to
     975   support random access.
    944976</t>
    945977</section>
    … …  
    12041236<t>
    12051237   When a <x:ref>206 (Partial Content)</x:ref> response message includes the
    1206    content of multiple ranges, they are transmitted as body-parts in a
     1238   content of multiple ranges, they are transmitted as body parts in a
    12071239   multipart message body (<xref target="RFC2046" x:fmt="," x:sec="5.1"/>)
    12081240   with the media type of "multipart/byteranges".  The following definition is
    … …  
    12101242</t>
    12111243<t>
    1212    The multipart/byteranges media type includes one or more body-parts, each
     1244   The multipart/byteranges media type includes one or more body parts, each
    12131245   with its own <x:ref>Content-Type</x:ref> and <x:ref>Content-Range</x:ref>
    12141246   fields. The required boundary parameter specifies the boundary string used
    1215    to separate each body-part.
     1247   to separate each body part.
    12161248</t>
    12171249<t>
Note: See TracChangeset for help on using the changeset viewer.