Source: http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1542
Timestamp: 2015-03-31 16:47:44
Document Index: 257661395

Matched Legal Cases: ['art 5', 'art 5', 'art4', 'art4', 'art 4', 'art4', 'art4', 'art4', 'art 4', 'art4', 'art4', 'art4', 'art 4', 'art4', 'art1', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art 498', 'art 672']

Changeset 1542 – httpbis
Changeset 1542
2012-02-20 09:20:33
ylafon@w3.org
460460 } 461461 @bottom-center { 462 content: "Expires August 10, 2012"; 462 content: "Expires August 23, 2012"; 463463 } 464464 @bottom-right { …
485485 <link rel="Chapter" title="2 Range Units" href="#rfc.section.2"> 486486 <link rel="Chapter" title="3 Status Code Definitions" href="#rfc.section.3"> 487 <link rel="Chapter" title="4 Combining Ranges" href="#rfc.section.4"> 487 <link rel="Chapter" title="4 Responses to a Range Request" href="#rfc.section.4"> 488488 <link rel="Chapter" title="5 Header Field Definitions" href="#rfc.section.5"> 489489 <link rel="Chapter" title="6 IANA Considerations" href="#rfc.section.6"> …
509509 <meta name="dct.creator" content="Reschke, J. F."> 510510 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest"> 511 <meta name="dct.issued" scheme="ISO8601" content="2012-02-07"> 511 <meta name="dct.issued" scheme="ISO8601" content="2012-02-20"> 512512 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 513513 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext 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."> …
535535 </tr> 536536 <tr> 537 <td class="left">Expires: August 10, 2012</td> 537 <td class="left">Expires: August 23, 2012</td> 538538 <td class="right">J. Mogul</td> 539539 </tr> …
592592 <tr> 593593 <td class="left"></td> 594 <td class="right">February 7, 2012</td> 594 <td class="right">February 20, 2012</td> 595595 </tr> 596596 </tbody> …
620620 in progress”. 621621 </p> 622 <p>This Internet-Draft will expire on August 10, 2012.</p> 622 <p>This Internet-Draft will expire on August 23, 2012.</p> 623623 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 624624 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> …
656656 </ul> 657657 </li> 658 <li>4.&nbsp;&nbsp;&nbsp;<a href="#combining.byte.ranges">Combining Ranges</a></li> 658 <li>4.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4">Responses to a Range Request</a><ul> 659 <li>4.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.1">Response to a Single and Multiple Ranges Request</a></li> 660 <li>4.2&nbsp;&nbsp;&nbsp;<a href="#combining.byte.ranges">Combining Ranges</a></li> 661 </ul> 662 </li> 659663 <li>5.&nbsp;&nbsp;&nbsp;<a href="#header.field.definitions">Header Field Definitions</a><ul> 660664 <li>5.1&nbsp;&nbsp;&nbsp;<a href="#header.accept-ranges">Accept-Ranges</a></li> …
820824 length of the selected resource.) 821825 </p> 822 <p id="rfc.section.3.2.p.2">When this status code is returned for a byte-range request, the response <em class="bcp14">SHOULD</em> include a Content-Range header field specifying the current length of the representation (see <a href="#header.content-range" id="rfc.xref.header.content-range.3" title="Content-Range">Section&nbsp;5.2</a>). This response <em class="bcp14">MUST NOT</em> use the multipart/byteranges content-type. 823 </p> 824 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="combining.byte.ranges" href="#combining.byte.ranges">Combining Ranges</a></h1> 825 <p id="rfc.section.4.p.1">A response might transfer only a subrange of a representation if the connection closed prematurely or if the request used 826 <p id="rfc.section.3.2.p.2">When this status code is returned for a byte-range request, the response <em class="bcp14">SHOULD</em> include a Content-Range header field specifying the current length of the representation (see <a href="#header.content-range" id="rfc.xref.header.content-range.3" title="Content-Range">Section&nbsp;5.2</a>). This response <em class="bcp14">MUST NOT</em> use the multipart/byteranges content-type. For example, 827 </p> 828 <div id="rfc.figure.u.4"></div><pre class="text"> HTTP/1.1 416 Requested Range Not Satisfiable 829 Date: Mon, 20 Jan 2012 15:41:54 GMT 830 Content-Range: bytes */47022 831 Content-Type: image/gif 832</pre><div class="note" id="rfc.section.3.2.p.4"> 833 <p> <b>Note:</b> Clients cannot depend on servers to send a 416 (Requested range not satisfiable) response instead of a 200 (OK) response for 834 an unsatisfiable Range header field, since not all servers implement this header field. 835 </p> 836 </div> 837 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;Responses to a Range Request 838 </h1> 839 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;Response to a Single and Multiple Ranges Request 840 </h2> 841 <p id="rfc.section.4.1.p.1">When an HTTP message includes the content of a single range (for example, a response to a request for a single range, or to 842 a request for a set of ranges that overlap without any holes), this content is transmitted with a Content-Range header field, 843 and a Content-Length header field showing the number of bytes actually transferred. For example, 844 </p> 845 <div id="rfc.figure.u.5"></div><pre class="text"> HTTP/1.1 206 Partial Content 846 Date: Wed, 15 Nov 1995 06:25:24 GMT 847 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 848 Content-Range: bytes 21010-47021/47022 849 Content-Length: 26012 850 Content-Type: image/gif 851</pre><p id="rfc.section.4.1.p.3">When an HTTP message includes the content of multiple ranges (for example, a response to a request for multiple non-overlapping 852 ranges), these are transmitted as a multipart message. The multipart media type used for this purpose is "multipart/byteranges" 853 as defined in <a href="#internet.media.type.multipart.byteranges" title="Internet Media Type multipart/byteranges">Appendix&nbsp;A</a>. 854 </p> 855 <p id="rfc.section.4.1.p.4">A server can combine requested ranges when those ranges are overlapping (See <a href="#security.considerations" title="Security Considerations">Section&nbsp;7</a>). 856 </p> 857 <p id="rfc.section.4.1.p.5">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. 858 </p> 859 <p id="rfc.section.4.1.p.6">When a client requests multiple ranges in one request, the server <em class="bcp14">SHOULD</em> return them in the order that they appeared in the request. 860 </p> 861 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="combining.byte.ranges" href="#combining.byte.ranges">Combining Ranges</a></h2> 862 <p id="rfc.section.4.2.p.1">A response might transfer only a subrange of a representation if the connection closed prematurely or if the request used 826863 one or more Range specifications. After several such transfers, a client might have received several ranges of the same representation. 827864 These ranges can only be safely combined if they all have in common the same strong validator, where "strong validator" is 828865 defined to be either an entity-tag that is not marked as weak (<a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) or, if no entity-tag is provided, a Last-Modified value that 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.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>. 829866 </p> 830 <p id="rfc.section.4.p.2">When a client receives an incomplete 200 (OK) or 206 (Partial Content) response and already has one or more stored responses 867 <p id="rfc.section.4.2.p.2">When a client receives an incomplete 200 (OK) or 206 (Partial Content) response and already has one or more stored responses 831868 for the same method and effective request URI, all of the stored responses with the same strong validator <em class="bcp14">MAY</em> be combined with the partial content in this new response. If none of the stored responses contain the same strong validator, 832869 then this new response corresponds to a new representation and <em class="bcp14">MUST NOT</em> be combined with the existing stored responses. 833870 </p> 834 <p id="rfc.section.4.p.3">If the new response is an incomplete 200 (OK) response, then the header fields of that new response are used for any combined 871 <p id="rfc.section.4.2.p.3">If the new response is an incomplete 200 (OK) response, then the header fields of that new response are used for any combined 835872 response and replace those of the matching stored responses. 836873 </p> 837 <p id="rfc.section.4.p.4">If the new response is a 206 (Partial Content) response and at least one of the matching stored responses is a 200 (OK), then 874 <p id="rfc.section.4.2.p.4">If the new response is a 206 (Partial Content) response and at least one of the matching stored responses is a 200 (OK), then 838875 the combined response header fields consist of the most recent 200 response's header fields. If all of the matching stored 839876 responses are 206 responses, then the stored response with the most header fields is used as the source of header fields for …
841878 header fields in the stored response. 842879 </p> 843 <p id="rfc.section.4.p.5">The combined response message-body consists of the union of partial content ranges in the new response and each of the selected 880 <p id="rfc.section.4.2.p.5">The combined response message-body consists of the union of partial content ranges in the new response and each of the selected 844881 responses. If the union consists of the entire range of the representation, then the combined response <em class="bcp14">MUST</em> be recorded as a complete 200 (OK) response with a Content-Length header field that reflects the complete length. Otherwise, 845882 the combined response(s) <em class="bcp14">MUST</em> include a Content-Range header field describing the included range(s) and be recorded as incomplete. If the union consists …
852889 <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a id="header.accept-ranges" href="#header.accept-ranges">Accept-Ranges</a></h2> 853890 <p id="rfc.section.5.1.p.1">The "Accept-Ranges" header field allows a resource to indicate its acceptance of range requests.</p> 854 <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span> <a href="#header.accept-ranges" class="smpl">Accept-Ranges</a> = <a href="#header.accept-ranges" class="smpl">acceptable-ranges</a> 891 <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span> <a href="#header.accept-ranges" class="smpl">Accept-Ranges</a> = <a href="#header.accept-ranges" class="smpl">acceptable-ranges</a> 855892 <a href="#header.accept-ranges" class="smpl">acceptable-ranges</a> = 1#<a href="#range.units" class="smpl">range-unit</a> / "none" 856893</pre><p id="rfc.section.5.1.p.3">Origin servers that accept byte-range requests <em class="bcp14">MAY</em> send 857894 </p> 858 <div id="rfc.figure.u.5"></div><pre class="text"> Accept-Ranges: bytes 895 <div id="rfc.figure.u.7"></div><pre class="text"> Accept-Ranges: bytes 859896</pre><p id="rfc.section.5.1.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>. 860897 </p> 861898 <p id="rfc.section.5.1.p.6">Servers that do not accept any kind of range request for a resource <em class="bcp14">MAY</em> send 862899 </p> 863 <div id="rfc.figure.u.6"></div><pre class="text"> Accept-Ranges: none 900 <div id="rfc.figure.u.8"></div><pre class="text"> Accept-Ranges: none 864901</pre><p id="rfc.section.5.1.p.8">to advise the client not to attempt a range request.</p> 865902 <div id="rfc.iref.c.1"></div> …
871908 <p id="rfc.section.5.2.p.2">Range units are defined in <a href="#range.units" title="Range Units">Section&nbsp;2</a>. 872909 </p> 873 <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.6"></span><span id="rfc.iref.g.7"></span><span id="rfc.iref.g.8"></span><span id="rfc.iref.g.9"></span> <a href="#header.content-range" class="smpl">Content-Range</a> = <a href="#header.content-range" class="smpl">byte-content-range-spec</a> 910 <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.6"></span><span id="rfc.iref.g.7"></span><span id="rfc.iref.g.8"></span><span id="rfc.iref.g.9"></span> <a href="#header.content-range" class="smpl">Content-Range</a> = <a href="#header.content-range" class="smpl">byte-content-range-spec</a> 874911 / <a href="#header.content-range" class="smpl">other-content-range-spec</a> 875912 …
903940 <ul> 904941 <li>The first 500 bytes: 905 <div id="rfc.figure.u.8"></div><pre class="text"> bytes 0-499/1234 942 <div id="rfc.figure.u.10"></div><pre class="text"> bytes 0-499/1234 906943</pre> </li> 907944 <li>The second 500 bytes: 908 <div id="rfc.figure.u.9"></div><pre class="text"> bytes 500-999/1234 945 <div id="rfc.figure.u.11"></div><pre class="text"> bytes 500-999/1234 909946</pre> </li> 910947 <li>All except for the first 500 bytes: 911 <div id="rfc.figure.u.10"></div><pre class="text"> bytes 500-1233/1234 948 <div id="rfc.figure.u.12"></div><pre class="text"> bytes 500-1233/1234 912949</pre> </li> 913950 <li>The last 500 bytes: 914 <div id="rfc.figure.u.11"></div><pre class="text"> bytes 734-1233/1234 951 <div id="rfc.figure.u.13"></div><pre class="text"> bytes 734-1233/1234 915952</pre> </li> 916953 </ul> 917 <p id="rfc.section.5.2.p.10">When an HTTP message includes the content of a single range (for example, a response to a request for a single range, or to 918 a request for a set of ranges that overlap without any holes), this content is transmitted with a Content-Range header field, 919 and a Content-Length header field showing the number of bytes actually transferred. For example, 920 </p> 921 <div id="rfc.figure.u.12"></div><pre class="text"> HTTP/1.1 206 Partial Content 922 Date: Wed, 15 Nov 1995 06:25:24 GMT 923 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 924 Content-Range: bytes 21010-47021/47022 925 Content-Length: 26012 926 Content-Type: image/gif 927 </pre><p id="rfc.section.5.2.p.12">When an HTTP message includes the content of multiple ranges (for example, a response to a request for multiple non-overlapping 928 ranges), these are transmitted as a multipart message. The multipart media type used for this purpose is "multipart/byteranges" 929 as defined in <a href="#internet.media.type.multipart.byteranges" title="Internet Media Type multipart/byteranges">Appendix&nbsp;A</a>. 930 </p> 931 <p id="rfc.section.5.2.p.13">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. 932 </p> 933 <p id="rfc.section.5.2.p.14">When a client requests multiple ranges in one request, the server <em class="bcp14">SHOULD</em> return them in the order that they appeared in the request. 934 </p> 935 <p id="rfc.section.5.2.p.15">If the server ignores a byte-range-spec because it is syntactically invalid, the server <em class="bcp14">SHOULD</em> treat the request as if the invalid Range header field did not exist. (Normally, this means return a 200 response containing 954 <p id="rfc.section.5.2.p.10">If the server ignores a byte-range-spec (for example if it is syntactically invalid, or if it may be seen as a denial-of-service 955 attack), the server <em class="bcp14">SHOULD</em> treat the request as if the invalid Range header field did not exist. (Normally, this means return a 200 response containing 936956 the full representation). 937957 </p> 938 <p id="rfc.section.5.2.p.16">If the server receives a request (other than one including an If-Range header field) with an unsatisfiable Range header field 939 (that is, all of whose byte-range-spec values have a first-byte-pos value greater than the current length of the selected 940 resource), it <em class="bcp14">SHOULD</em> return a response code of 416 (Requested range not satisfiable) (<a href="#status.416" id="rfc.xref.status.416.1" title="416 Requested Range Not Satisfiable">Section&nbsp;3.2</a>). 941 </p> 942 <div class="note" id="rfc.section.5.2.p.17"> 943 <p> <b>Note:</b> Clients cannot depend on servers to send a 416 (Requested range not satisfiable) response instead of a 200 (OK) response for 944 an unsatisfiable Range header field, since not all servers implement this header field. 945 </p> 946 </div> 947958 <div id="rfc.iref.i.1"></div> 948959 <div id="rfc.iref.h.3"></div> …
956967 is unchanged, send me the part(s) that I am missing; otherwise, send me the entire new representation". 957968 </p> 958 <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.10"></span> <a href="#header.if-range" class="smpl">If-Range</a> = <a href="#abnf.dependencies" class="smpl">entity-tag</a> / <a href="#core.rules" class="smpl">HTTP-date</a> 969 <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.10"></span> <a href="#header.if-range" class="smpl">If-Range</a> = <a href="#abnf.dependencies" class="smpl">entity-tag</a> / <a href="#core.rules" class="smpl">HTTP-date</a> 959970</pre><p id="rfc.section.5.3.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 Last-Modified date in an If-Range field value unless it has no entity-tag for the representation and the Last-Modified 960971 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.4"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>. …
983994 </p> 984995 </div> 985 <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span><span id="rfc.iref.g.16"></span> <a href="#rule.ranges-specifier" class="smpl">byte-ranges-specifier</a> = <a href="#range.units" class="smpl">bytes-unit</a> "=" <a href="#rule.ranges-specifier" class="smpl">byte-range-set</a> 996 <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span><span id="rfc.iref.g.16"></span> <a href="#rule.ranges-specifier" class="smpl">byte-ranges-specifier</a> = <a href="#range.units" class="smpl">bytes-unit</a> "=" <a href="#rule.ranges-specifier" class="smpl">byte-range-set</a> 986997 <a href="#rule.ranges-specifier" class="smpl">byte-range-set</a> = 1#( <a href="#rule.ranges-specifier" class="smpl">byte-range-spec</a> / <a href="#rule.ranges-specifier" class="smpl">suffix-byte-range-spec</a> ) 987998 <a href="#rule.ranges-specifier" class="smpl">byte-range-spec</a> = <a href="#rule.ranges-specifier" class="smpl">first-byte-pos</a> "-" [ <a href="#rule.ranges-specifier" class="smpl">last-byte-pos</a> ] …
9991010 </p> 10001011 <p id="rfc.section.5.4.1.p.8">By its choice of last-byte-pos, a client can limit the number of bytes retrieved without knowing the size of the representation.</p> 1001 <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span> <a href="#rule.ranges-specifier" class="smpl">suffix-byte-range-spec</a> = "-" <a href="#rule.ranges-specifier" class="smpl">suffix-length</a> 1012 <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span> <a href="#rule.ranges-specifier" class="smpl">suffix-byte-range-spec</a> = "-" <a href="#rule.ranges-specifier" class="smpl">suffix-length</a> 10021013 <a href="#rule.ranges-specifier" class="smpl">suffix-length</a> = 1*<a href="#notation" class="smpl">DIGIT</a> 10031014</pre><p id="rfc.section.5.4.1.p.10">A suffix-byte-range-spec is used to specify the suffix of the representation body, of a length given by the suffix-length …
10121023 <ul> 10131024 <li>The first 500 bytes (byte offsets 0-499, inclusive): 1014 <div id="rfc.figure.u.16"></div><pre class="text"> bytes=0-499 1025 <div id="rfc.figure.u.17"></div><pre class="text"> bytes=0-499 10151026</pre> </li> 10161027 <li>The second 500 bytes (byte offsets 500-999, inclusive): 1017 <div id="rfc.figure.u.17"></div><pre class="text"> bytes=500-999 1028 <div id="rfc.figure.u.18"></div><pre class="text"> bytes=500-999 10181029</pre> </li> 10191030 <li>The final 500 bytes (byte offsets 9500-9999, inclusive): 1020 <div id="rfc.figure.u.18"></div><pre class="text"> bytes=-500 1021 </pre> Or: <div id="rfc.figure.u.19"></div><pre class="text"> bytes=9500- 1031 <div id="rfc.figure.u.19"></div><pre class="text"> bytes=-500 1032</pre> Or: <div id="rfc.figure.u.20"></div><pre class="text"> bytes=9500- 10221033</pre> </li> 10231034 <li>The first and last bytes only (bytes 0 and 9999): 1024 <div id="rfc.figure.u.20"></div><pre class="text"> bytes=0-0,-1 1035 <div id="rfc.figure.u.21"></div><pre class="text"> bytes=0-0,-1 10251036</pre> </li> 10261037 <li>Several legal but not canonical specifications of the second 500 bytes (byte offsets 500-999, inclusive): 1027 <div id="rfc.figure.u.21"></div><pre class="text"> bytes=500-600,601-999 1038 <div id="rfc.figure.u.22"></div><pre class="text"> bytes=500-600,601-999 10281039 bytes=500-700,601-999 10291040</pre> </li> …
10331044 body, instead of the entire representation body. 10341045 </p> 1035 <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.19"></span> <a href="#range.retrieval.requests" class="smpl">Range</a> = <a href="#rule.ranges-specifier" class="smpl">byte-ranges-specifier</a> / <a href="#range.retrieval.requests" class="smpl">other-ranges-specifier</a> 1046 <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.19"></span> <a href="#range.retrieval.requests" class="smpl">Range</a> = <a href="#rule.ranges-specifier" class="smpl">byte-ranges-specifier</a> / <a href="#range.retrieval.requests" class="smpl">other-ranges-specifier</a> 10361047 <a href="#range.retrieval.requests" class="smpl">other-ranges-specifier</a> = <a href="#range.units" class="smpl">other-range-unit</a> "=" <a href="#range.retrieval.requests" class="smpl">other-range-set</a> 10371048 <a href="#range.retrieval.requests" class="smpl">other-range-set</a> = 1*<a href="#notation" class="smpl">CHAR</a> …
10791090 <td class="left">416</td> 10801091 <td class="left">Requested Range Not Satisfiable</td> 1081 <td class="left"> <a href="#status.416" id="rfc.xref.status.416.2" title="416 Requested Range Not Satisfiable">Section&nbsp;3.2</a> 1092 <td class="left"> <a href="#status.416" id="rfc.xref.status.416.1" title="416 Requested Range Not Satisfiable">Section&nbsp;3.2</a> 10821093 </td> 10831094 </tr> …
13051316 <dd>IESG</dd> 13061317 </dl> 1307 <div id="rfc.figure.u.23"></div> 1318 <div id="rfc.figure.u.24"></div> 13081319 <p>For example:</p><pre class="text"> HTTP/1.1 206 Partial Content 13091320 Date: Wed, 15 Nov 1995 06:25:24 GMT …
13221333 ...the second range 13231334 --THIS_STRING_SEPARATES-- 1324 </pre><div id="rfc.figure.u.24"></div> 1335</pre><div id="rfc.figure.u.25"></div> 13251336 <p>Other example:</p> <pre class="text"> HTTP/1.1 206 Partial Content 13261337 Date: Tue, 14 Nov 1995 06:25:24 GMT …
13571368 </p> 13581369 <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 1359 <div id="rfc.figure.u.25"></div> <pre class="inline"><a href="#header.accept-ranges" class="smpl">Accept-Ranges</a> = acceptable-ranges 1370 <div id="rfc.figure.u.26"></div> <pre class="inline"><a href="#header.accept-ranges" class="smpl">Accept-Ranges</a> = acceptable-ranges 13601371 13611372<a href="#header.content-range" class="smpl">Content-Range</a> = byte-content-range-spec / other-content-range-spec …
14021413 14031414<a href="#core.rules" class="smpl">token</a> = &lt;token, defined in [Part1], Section 3.2.4&gt; 1404 </pre> <div id="rfc.figure.u.26"></div> 1415</pre> <div id="rfc.figure.u.27"></div> 14051416 <p>ABNF diagnostics:</p><pre class="inline">; Accept-Ranges defined but not used 14061417; Content-Range defined but not used …
15471558 <p id="rfc.section.D.19.p.1">None.</p> 15481559 <h2 id="rfc.section.D.20"><a href="#rfc.section.D.20">D.20</a>&nbsp;<a id="changes.since.18" href="#changes.since.18">Since draft-ietf-httpbis-p5-range-18</a></h2> 1549 <p id="rfc.section.D.20.p.1">None yet.</p> 1560 <p id="rfc.section.D.20.p.1">Closed issues: </p> 1561 <ul> 1562 <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/311">http://tools.ietf.org/wg/httpbis/trac/ticket/311</a>&gt;: "Add limitations to Range to reduce its use as a denial-of-service tool" 1563 </li> 1564 </ul> 15501565 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 15511566 <p class="noprint"><a href="#rfc.index.2">2</a> <a href="#rfc.index.4">4</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> …
15581573 </li> 15591574 <li><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul> 1560 <li>416 Requested Range Not Satisfiable (status code)&nbsp;&nbsp;<a href="#rfc.iref.4"><b>3.2</b></a>, <a href="#rfc.xref.status.416.1">5.2</a>, <a href="#rfc.xref.status.416.2">6.1</a></li> 1575 <li>416 Requested Range Not Satisfiable (status code)&nbsp;&nbsp;<a href="#rfc.iref.4"><b>3.2</b></a>, <a href="#rfc.xref.status.416.1">6.1</a></li> 15611576 </ul> 15621577 </li> …
16341649 </ul> 16351650 </li> 1636 <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">1.2.2</a>, <a href="#rfc.xref.Part4.2">4</a>, <a href="#rfc.xref.Part4.3">4</a>, <a href="#rfc.xref.Part4.4">5.3</a>, <a href="#rfc.xref.Part4.5">5.3</a>, <a href="#Part4"><b>9.1</b></a><ul> 1637 <li><em>Section 2.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.3">4</a>, <a href="#rfc.xref.Part4.4">5.3</a>, <a href="#rfc.xref.Part4.5">5.3</a></li> 1638 <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">1.2.2</a>, <a href="#rfc.xref.Part4.2">4</a></li> 1651 <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">1.2.2</a>, <a href="#rfc.xref.Part4.2">4.2</a>, <a href="#rfc.xref.Part4.3">4.2</a>, <a href="#rfc.xref.Part4.4">5.3</a>, <a href="#rfc.xref.Part4.5">5.3</a>, <a href="#Part4"><b>9.1</b></a><ul> 1652 <li><em>Section 2.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.3">4.2</a>, <a href="#rfc.xref.Part4.4">5.3</a>, <a href="#rfc.xref.Part4.5">5.3</a></li> 1653 <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">1.2.2</a>, <a href="#rfc.xref.Part4.2">4.2</a></li> 16391654 </ul> 16401655 </li> …
16691684 <ul> 16701685 <li>206 Partial Content&nbsp;&nbsp;<a href="#rfc.iref.s.1"><b>3.1</b></a>, <a href="#rfc.xref.status.206.1">6.1</a>, <a href="#rfc.xref.status.206.2">B.1</a></li> 1671 <li>416 Requested Range Not Satisfiable&nbsp;&nbsp;<a href="#rfc.iref.s.2"><b>3.2</b></a>, <a href="#rfc.xref.status.416.1">5.2</a>, <a href="#rfc.xref.status.416.2">6.1</a></li> 1686 <li>416 Requested Range Not Satisfiable&nbsp;&nbsp;<a href="#rfc.iref.s.2"><b>3.2</b></a>, <a href="#rfc.xref.status.416.1">6.1</a></li> 16721687 </ul> 16731688 </li> draft-ietf-httpbis/latest/p5-range.xml
456456 response &SHOULD; include a Content-Range header field 457457 specifying the current length of the representation (see <xref target="header.content-range"/>). 458 This response &MUST-NOT; use the multipart/byteranges content-type. 459 </t> 460 </section> 458 This response &MUST-NOT; use the multipart/byteranges content-type. For example, 459</t> 460<figure><artwork type="example"> 461 HTTP/1.1 416 Requested Range Not Satisfiable 462 Date: Mon, 20 Jan 2012 15:41:54 GMT 463 Content-Range: bytes */47022 464 Content-Type: image/gif 465</artwork></figure> 466<x:note> 467 <t> 468 <x:h>Note:</x:h> Clients cannot depend on servers to send a 416 (Requested 469 range not satisfiable) response instead of a 200 (OK) response for 470 an unsatisfiable Range header field, since not all servers 471 implement this header field. 472 </t> 473</x:note> 474</section> 475</section> 476 477<section title="Responses to a Range Request"> 478<section title="Response to a Single and Multiple Ranges Request"> 479<t> 480 When an HTTP message includes the content of a single range (for 481 example, a response to a request for a single range, or to a request 482 for a set of ranges that overlap without any holes), this content is 483 transmitted with a Content-Range header field, and a Content-Length header 484 field showing the number of bytes actually transferred. For example, 485</t> 486<figure><artwork type="example"> 487 HTTP/1.1 206 Partial Content 488 Date: Wed, 15 Nov 1995 06:25:24 GMT 489 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 490 Content-Range: bytes 21010-47021/47022 491 Content-Length: 26012 492 Content-Type: image/gif 493</artwork></figure> 494<t> 495 When an HTTP message includes the content of multiple ranges (for 496 example, a response to a request for multiple non-overlapping 497 ranges), these are transmitted as a multipart message. The multipart 498 media type used for this purpose is "multipart/byteranges" as defined 499 in <xref target="internet.media.type.multipart.byteranges"/>. 500</t> 501<t> 502 A server &MAY; combine requested ranges when those ranges are overlapping 503 (See <xref target="security.considerations"/>). 504</t> 505<t> 506 A response to a request for a single range &MUST-NOT; be sent using the 507 multipart/byteranges media type. A response to a request for 508 multiple ranges, whose result is a single range, &MAY; be sent as a 509 multipart/byteranges media type with one part. A client that cannot 510 decode a multipart/byteranges message &MUST-NOT; ask for multiple 511 ranges in a single request. 512</t> 513<t> 514 When a client requests multiple ranges in one request, the 515 server &SHOULD; return them in the order that they appeared in the 516 request. 517</t> 461518</section> 462519 …
510567 response or as multiple 206 responses with one continuous range each. 511568</t> 569</section> 512570</section> 513571 …
652710</t> 653711<t> 654 When an HTTP message includes the content of a single range (for 655 example, a response to a request for a single range, or to a request 656 for a set of ranges that overlap without any holes), this content is 657 transmitted with a Content-Range header field, and a Content-Length header 658 field showing the number of bytes actually transferred. For example, 659 </t> 660 <figure><artwork type="example"> 661 HTTP/1.1 206 Partial Content 662 Date: Wed, 15 Nov 1995 06:25:24 GMT 663 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 664 Content-Range: bytes 21010-47021/47022 665 Content-Length: 26012 666 Content-Type: image/gif 667 </artwork></figure> 668 <t> 669 When an HTTP message includes the content of multiple ranges (for 670 example, a response to a request for multiple non-overlapping 671 ranges), these are transmitted as a multipart message. The multipart 672 media type used for this purpose is "multipart/byteranges" as defined 673 in <xref target="internet.media.type.multipart.byteranges"/>. 674 </t> 675 <t> 676 A response to a request for a single range &MUST-NOT; be sent using the 677 multipart/byteranges media type. A response to a request for 678 multiple ranges, whose result is a single range, &MAY; be sent as a 679 multipart/byteranges media type with one part. A client that cannot 680 decode a multipart/byteranges message &MUST-NOT; ask for multiple 681 ranges in a single request. 682 </t> 683 <t> 684 When a client requests multiple ranges in one request, the 685 server &SHOULD; return them in the order that they appeared in the 686 request. 687 </t> 688 <t> 689 If the server ignores a byte-range-spec because it is syntactically 690 invalid, the server &SHOULD; treat the request as if the invalid Range 712 If the server ignores a byte-range-spec (for example if it is 713 syntactically invalid, or if it may be seen as a denial-of-service 714 attack), the server &SHOULD; treat the request as if the invalid Range 691715 header field did not exist. (Normally, this means return a 200 692716 response containing the full representation). 693717</t> 694 <t> 695 If the server receives a request (other than one including an If-Range 696 header field) with an unsatisfiable Range header 697 field (that is, all of whose byte-range-spec values have a 698 first-byte-pos value greater than the current length of the selected 699 resource), it &SHOULD; return a response code of 416 (Requested range 700 not satisfiable) (<xref target="status.416"/>). 701 </t> 702 <x:note> 703 <t> 704 <x:h>Note:</x:h> Clients cannot depend on servers to send a 416 (Requested 705 range not satisfiable) response instead of a 200 (OK) response for 706 an unsatisfiable Range header field, since not all servers 707 implement this header field. 708 </t> 709 </x:note> 710718</section> 711719 …
18791887<section title="Since draft-ietf-httpbis-p5-range-18" anchor="changes.since.18"> 18801888<t> 1881 None yet. 1889 Closed issues: 1890 <list style="symbols"> 1891 <t> 1892 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/311"/>: 1893 "Add limitations to Range to reduce its use as a denial-of-service tool" 1894 </t> 1895 </list> 18821896</t> 18831897</section> Note: See TracChangeset