Changeset 1542 for draft-ietf-httpbis/latest
- Timestamp:
- 20/02/12 17:20:33 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p5-range.html
r1528 r1542 460 460 } 461 461 @bottom-center { 462 content: "Expires August 10, 2012";462 content: "Expires August 23, 2012"; 463 463 } 464 464 @bottom-right { … … 485 485 <link rel="Chapter" title="2 Range Units" href="#rfc.section.2"> 486 486 <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"> 488 488 <link rel="Chapter" title="5 Header Field Definitions" href="#rfc.section.5"> 489 489 <link rel="Chapter" title="6 IANA Considerations" href="#rfc.section.6"> … … 509 509 <meta name="dct.creator" content="Reschke, J. F."> 510 510 <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"> 512 512 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 513 513 <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 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests."> … … 535 535 </tr> 536 536 <tr> 537 <td class="left">Expires: August 10, 2012</td>537 <td class="left">Expires: August 23, 2012</td> 538 538 <td class="right">J. Mogul</td> 539 539 </tr> … … 592 592 <tr> 593 593 <td class="left"></td> 594 <td class="right">February 7, 2012</td>594 <td class="right">February 20, 2012</td> 595 595 </tr> 596 596 </tbody> … … 620 620 in progress”. 621 621 </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> 623 623 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 624 624 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 656 656 </ul> 657 657 </li> 658 <li>4. <a href="#combining.byte.ranges">Combining Ranges</a></li> 658 <li>4. <a href="#rfc.section.4">Responses to a Range Request</a><ul> 659 <li>4.1 <a href="#rfc.section.4.1">Response to a Single and Multiple Ranges Request</a></li> 660 <li>4.2 <a href="#combining.byte.ranges">Combining Ranges</a></li> 661 </ul> 662 </li> 659 663 <li>5. <a href="#header.field.definitions">Header Field Definitions</a><ul> 660 664 <li>5.1 <a href="#header.accept-ranges">Accept-Ranges</a></li> … … 820 824 length of the selected resource.) 821 825 </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 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> <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 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> Responses to a Range Request 838 </h1> 839 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> 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 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 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> <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 826 863 one or more Range specifications. After several such transfers, a client might have received several ranges of the same representation. 827 864 These ranges can only be safely combined if they all have in common the same strong validator, where "strong validator" is 828 865 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>. 829 866 </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 responses867 <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 831 868 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, 832 869 then this new response corresponds to a new representation and <em class="bcp14">MUST NOT</em> be combined with the existing stored responses. 833 870 </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 combined871 <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 835 872 response and replace those of the matching stored responses. 836 873 </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), then874 <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 838 875 the combined response header fields consist of the most recent 200 response's header fields. If all of the matching stored 839 876 responses are 206 responses, then the stored response with the most header fields is used as the source of header fields for … … 841 878 header fields in the stored response. 842 879 </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 selected880 <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 844 881 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, 845 882 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 … … 852 889 <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> <a id="header.accept-ranges" href="#header.accept-ranges">Accept-Ranges</a></h2> 853 890 <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> 855 892 <a href="#header.accept-ranges" class="smpl">acceptable-ranges</a> = 1#<a href="#range.units" class="smpl">range-unit</a> / "none" 856 893 </pre><p id="rfc.section.5.1.p.3">Origin servers that accept byte-range requests <em class="bcp14">MAY</em> send 857 894 </p> 858 <div id="rfc.figure.u. 5"></div><pre class="text"> Accept-Ranges: bytes895 <div id="rfc.figure.u.7"></div><pre class="text"> Accept-Ranges: bytes 859 896 </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 2</a>. 860 897 </p> 861 898 <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 862 899 </p> 863 <div id="rfc.figure.u. 6"></div><pre class="text"> Accept-Ranges: none900 <div id="rfc.figure.u.8"></div><pre class="text"> Accept-Ranges: none 864 901 </pre><p id="rfc.section.5.1.p.8">to advise the client not to attempt a range request.</p> 865 902 <div id="rfc.iref.c.1"></div> … … 871 908 <p id="rfc.section.5.2.p.2">Range units are defined in <a href="#range.units" title="Range Units">Section 2</a>. 872 909 </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> 874 911 / <a href="#header.content-range" class="smpl">other-content-range-spec</a> 875 912 … … 903 940 <ul> 904 941 <li>The first 500 bytes: 905 <div id="rfc.figure.u. 8"></div><pre class="text"> bytes 0-499/1234942 <div id="rfc.figure.u.10"></div><pre class="text"> bytes 0-499/1234 906 943 </pre> </li> 907 944 <li>The second 500 bytes: 908 <div id="rfc.figure.u. 9"></div><pre class="text"> bytes 500-999/1234945 <div id="rfc.figure.u.11"></div><pre class="text"> bytes 500-999/1234 909 946 </pre> </li> 910 947 <li>All except for the first 500 bytes: 911 <div id="rfc.figure.u.1 0"></div><pre class="text"> bytes 500-1233/1234948 <div id="rfc.figure.u.12"></div><pre class="text"> bytes 500-1233/1234 912 949 </pre> </li> 913 950 <li>The last 500 bytes: 914 <div id="rfc.figure.u.1 1"></div><pre class="text"> bytes 734-1233/1234951 <div id="rfc.figure.u.13"></div><pre class="text"> bytes 734-1233/1234 915 952 </pre> </li> 916 953 </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 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 936 956 the full representation). 937 957 </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 field939 (that is, all of whose byte-range-spec values have a first-byte-pos value greater than the current length of the selected940 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 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 for944 an unsatisfiable Range header field, since not all servers implement this header field.945 </p>946 </div>947 958 <div id="rfc.iref.i.1"></div> 948 959 <div id="rfc.iref.h.3"></div> … … 956 967 is unchanged, send me the part(s) that I am missing; otherwise, send me the entire new representation". 957 968 </p> 958 <div id="rfc.figure.u.1 3"></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> 959 970 </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 960 971 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>. … … 983 994 </p> 984 995 </div> 985 <div id="rfc.figure.u.1 4"></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> 986 997 <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> ) 987 998 <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> ] … … 999 1010 </p> 1000 1011 <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.1 5"></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> 1002 1013 <a href="#rule.ranges-specifier" class="smpl">suffix-length</a> = 1*<a href="#notation" class="smpl">DIGIT</a> 1003 1014 </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 … … 1012 1023 <ul> 1013 1024 <li>The first 500 bytes (byte offsets 0-499, inclusive): 1014 <div id="rfc.figure.u.1 6"></div><pre class="text"> bytes=0-4991025 <div id="rfc.figure.u.17"></div><pre class="text"> bytes=0-499 1015 1026 </pre> </li> 1016 1027 <li>The second 500 bytes (byte offsets 500-999, inclusive): 1017 <div id="rfc.figure.u.1 7"></div><pre class="text"> bytes=500-9991028 <div id="rfc.figure.u.18"></div><pre class="text"> bytes=500-999 1018 1029 </pre> </li> 1019 1030 <li>The final 500 bytes (byte offsets 9500-9999, inclusive): 1020 <div id="rfc.figure.u.1 8"></div><pre class="text"> bytes=-5001021 </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- 1022 1033 </pre> </li> 1023 1034 <li>The first and last bytes only (bytes 0 and 9999): 1024 <div id="rfc.figure.u.2 0"></div><pre class="text"> bytes=0-0,-11035 <div id="rfc.figure.u.21"></div><pre class="text"> bytes=0-0,-1 1025 1036 </pre> </li> 1026 1037 <li>Several legal but not canonical specifications of the second 500 bytes (byte offsets 500-999, inclusive): 1027 <div id="rfc.figure.u.2 1"></div><pre class="text"> bytes=500-600,601-9991038 <div id="rfc.figure.u.22"></div><pre class="text"> bytes=500-600,601-999 1028 1039 bytes=500-700,601-999 1029 1040 </pre> </li> … … 1033 1044 body, instead of the entire representation body. 1034 1045 </p> 1035 <div id="rfc.figure.u.2 2"></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> 1036 1047 <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> 1037 1048 <a href="#range.retrieval.requests" class="smpl">other-range-set</a> = 1*<a href="#notation" class="smpl">CHAR</a> … … 1079 1090 <td class="left">416</td> 1080 1091 <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 3.2</a>1092 <td class="left"> <a href="#status.416" id="rfc.xref.status.416.1" title="416 Requested Range Not Satisfiable">Section 3.2</a> 1082 1093 </td> 1083 1094 </tr> … … 1305 1316 <dd>IESG</dd> 1306 1317 </dl> 1307 <div id="rfc.figure.u.2 3"></div>1318 <div id="rfc.figure.u.24"></div> 1308 1319 <p>For example:</p><pre class="text"> HTTP/1.1 206 Partial Content 1309 1320 Date: Wed, 15 Nov 1995 06:25:24 GMT … … 1322 1333 ...the second range 1323 1334 --THIS_STRING_SEPARATES-- 1324 </pre><div id="rfc.figure.u.2 4"></div>1335 </pre><div id="rfc.figure.u.25"></div> 1325 1336 <p>Other example:</p> <pre class="text"> HTTP/1.1 206 Partial Content 1326 1337 Date: Tue, 14 Nov 1995 06:25:24 GMT … … 1357 1368 </p> 1358 1369 <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 1359 <div id="rfc.figure.u.2 5"></div> <pre class="inline"><a href="#header.accept-ranges" class="smpl">Accept-Ranges</a> = acceptable-ranges1370 <div id="rfc.figure.u.26"></div> <pre class="inline"><a href="#header.accept-ranges" class="smpl">Accept-Ranges</a> = acceptable-ranges 1360 1371 1361 1372 <a href="#header.content-range" class="smpl">Content-Range</a> = byte-content-range-spec / other-content-range-spec … … 1402 1413 1403 1414 <a href="#core.rules" class="smpl">token</a> = <token, defined in [Part1], Section 3.2.4> 1404 </pre> <div id="rfc.figure.u.2 6"></div>1415 </pre> <div id="rfc.figure.u.27"></div> 1405 1416 <p>ABNF diagnostics:</p><pre class="inline">; Accept-Ranges defined but not used 1406 1417 ; Content-Range defined but not used … … 1547 1558 <p id="rfc.section.D.19.p.1">None.</p> 1548 1559 <h2 id="rfc.section.D.20"><a href="#rfc.section.D.20">D.20</a> <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> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/311">http://tools.ietf.org/wg/httpbis/trac/ticket/311</a>>: "Add limitations to Range to reduce its use as a denial-of-service tool" 1563 </li> 1564 </ul> 1550 1565 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 1551 1566 <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> … … 1558 1573 </li> 1559 1574 <li><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul> 1560 <li>416 Requested Range Not Satisfiable (status code) <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) <a href="#rfc.iref.4"><b>3.2</b></a>, <a href="#rfc.xref.status.416.1">6.1</a></li> 1561 1576 </ul> 1562 1577 </li> … … 1634 1649 </ul> 1635 1650 </li> 1636 <li><em>Part4</em> <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> <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> <a href="#rfc.xref.Part4.1">1.2.2</a>, <a href="#rfc.xref.Part4.2">4 </a></li>1651 <li><em>Part4</em> <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> <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> <a href="#rfc.xref.Part4.1">1.2.2</a>, <a href="#rfc.xref.Part4.2">4.2</a></li> 1639 1654 </ul> 1640 1655 </li> … … 1669 1684 <ul> 1670 1685 <li>206 Partial Content <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 <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 <a href="#rfc.iref.s.2"><b>3.2</b></a>, <a href="#rfc.xref.status.416.1">6.1</a></li> 1672 1687 </ul> 1673 1688 </li> -
draft-ietf-httpbis/latest/p5-range.xml
r1524 r1542 456 456 response &SHOULD; include a Content-Range header field 457 457 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> 461 518 </section> 462 519 … … 510 567 response or as multiple 206 responses with one continuous range each. 511 568 </t> 569 </section> 512 570 </section> 513 571 … … 652 710 </t> 653 711 <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 691 715 header field did not exist. (Normally, this means return a 200 692 716 response containing the full representation). 693 717 </t> 694 <t>695 If the server receives a request (other than one including an If-Range696 header field) with an unsatisfiable Range header697 field (that is, all of whose byte-range-spec values have a698 first-byte-pos value greater than the current length of the selected699 resource), it &SHOULD; return a response code of 416 (Requested range700 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 (Requested705 range not satisfiable) response instead of a 200 (OK) response for706 an unsatisfiable Range header field, since not all servers707 implement this header field.708 </t>709 </x:note>710 718 </section> 711 719 … … 1879 1887 <section title="Since draft-ietf-httpbis-p5-range-18" anchor="changes.since.18"> 1880 1888 <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> 1882 1896 </t> 1883 1897 </section>
Note: See TracChangeset
for help on using the changeset viewer.