Changeset 2157 for draft-ietf-httpbis
- Timestamp:
- 24/01/13 12:02:20 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p5-range.html
r2153 r2157 449 449 } 450 450 @bottom-center { 451 content: "Expires July 2 7, 2013";451 content: "Expires July 28, 2013"; 452 452 } 453 453 @bottom-right { … … 492 492 <meta name="dct.creator" content="Reschke, J. F."> 493 493 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest"> 494 <meta name="dct.issued" scheme="ISO8601" content="2013-01-2 3">494 <meta name="dct.issued" scheme="ISO8601" content="2013-01-24"> 495 495 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 496 496 <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."> … … 518 518 </tr> 519 519 <tr> 520 <td class="left">Expires: July 2 7, 2013</td>520 <td class="left">Expires: July 28, 2013</td> 521 521 <td class="right">J. Reschke, Editor</td> 522 522 </tr> … … 527 527 <tr> 528 528 <td class="left"></td> 529 <td class="right">January 2 3, 2013</td>529 <td class="right">January 24, 2013</td> 530 530 </tr> 531 531 </tbody> … … 552 552 in progress”. 553 553 </p> 554 <p>This Internet-Draft will expire on July 2 7, 2013.</p>554 <p>This Internet-Draft will expire on July 28, 2013.</p> 555 555 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 556 556 <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 604 604 </li> 605 605 <li><a href="#rfc.section.6">6.</a> <a href="#security.considerations">Security Considerations</a><ul> 606 <li><a href="#rfc.section.6.1">6.1</a> <a href="#overlapping.ranges"> Overlapping Ranges</a></li>606 <li><a href="#rfc.section.6.1">6.1</a> <a href="#overlapping.ranges">Denial of Service Attacks using Range</a></li> 607 607 </ul> 608 608 </li> … … 745 745 when forwarding the request. 746 746 </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 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 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 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 752 761 range(s) are valid and satisfiable (as defined in <a href="#byte.ranges" title="Byte Ranges">Section 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, 753 762 as defined in <a href="#range.response" title="Responses to a Range Request">Section 4</a>. 754 763 </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 specified764 <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 756 765 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. 757 766 </p> … … 793 802 Content-Type: image/gif 794 803 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 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 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: 797 807 </p> 798 808 <div id="rfc.figure.u.18"></div><pre class="text">HTTP/1.1 206 Partial Content … … 813 823 ...the second range 814 824 --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 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 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. 832 843 </p> 833 844 <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. … … 860 871 <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. 861 872 </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 field873 <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 863 874 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 864 875 selected representation is known by the sender to be 1234 bytes: … … 915 926 length of the selected representation.) 916 927 </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 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 4.2</a>). 918 929 </p> 919 930 <div id="rfc.figure.u.27"></div> … … 1024 1035 <td class="left">http</td> 1025 1036 <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 4.2</a>1037 <td class="left"> <a href="#header.content-range" id="rfc.xref.header.content-range.3" title="Content-Range">Section 4.2</a> 1027 1038 </td> 1028 1039 </tr> … … 1049 1060 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>. 1050 1061 </p> 1051 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <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> <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. 1054 1068 </p> 1055 1069 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> … … 1136 1150 <div id="rfc.iref.m.2"></div> 1137 1151 <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a> <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. 1141 1155 </p> 1142 1156 <p id="rfc.section.A.p.3"> </p> … … 1212 1226 <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 4.1</a>) 1213 1227 </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 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 4.2</a>) 1215 1229 </p> 1216 1230 <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) … … 1331 1345 </li> 1332 1346 <li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul> 1333 <li>Content-Range header field <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 <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> 1334 1348 </ul> 1335 1349 </li> -
draft-ietf-httpbis/latest/p5-range.xml
r2153 r2157 396 396 </t> 397 397 <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> 398 417 The Range header field is evaluated after evaluating the preconditions of 399 418 <xref target="Part4"/> and only if the result of their evaluation is … … 506 525 Content-Type: image/gif 507 526 508 ... 26012 bytes of image data ...527 ... 26012 bytes of partial image data ... 509 528 </artwork></figure> 510 529 <t> … … 513 532 in <xref target="internet.media.type.multipart.byteranges"/>, and send a 514 533 <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="response"" 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="response"" x:indent-with=" "> 520 544 HTTP/1.1 206 Partial Content 521 545 Date: Wed, 15 Nov 1995 06:25:24 GMT … … 537 561 </artwork></figure> 538 562 <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>. 576 601 </t> 577 602 <t> 578 603 If a 206 is generated in response to a request with an <x:ref>If-Range</x:ref> 579 604 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 582 608 fields that would have been sent in a <x:ref>200 (OK)</x:ref> response 583 609 to the same request. … … 644 670 <t> 645 671 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 response672 byte range request &MUST; send, in each body part of a multipart response 647 673 or in the header block of a single part response, a Content-Range header 648 674 field containing a <x:ref>byte-range-resp</x:ref> value that reflects the … … 937 963 </t> 938 964 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. 944 976 </t> 945 977 </section> … … 1204 1236 <t> 1205 1237 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 a1238 content of multiple ranges, they are transmitted as body parts in a 1207 1239 multipart message body (<xref target="RFC2046" x:fmt="," x:sec="5.1"/>) 1208 1240 with the media type of "multipart/byteranges". The following definition is … … 1210 1242 </t> 1211 1243 <t> 1212 The multipart/byteranges media type includes one or more body -parts, each1244 The multipart/byteranges media type includes one or more body parts, each 1213 1245 with its own <x:ref>Content-Type</x:ref> and <x:ref>Content-Range</x:ref> 1214 1246 fields. The required boundary parameter specifies the boundary string used 1215 to separate each body -part.1247 to separate each body part. 1216 1248 </t> 1217 1249 <t>
Note: See TracChangeset
for help on using the changeset viewer.