Changeset 2158 for draft-ietf-httpbis
- Timestamp:
- 24/01/13 15:04:10 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p5-range.html
r2157 r2158 803 803 804 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: 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 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. To avoid confusion with single 806 part responses, a server <em class="bcp14">MUST NOT</em> generate a <a href="#header.content-range" class="smpl">Content-Range</a> header field in the HTTP header block of a multiple part response (this field will be sent in each part instead). 807 </p> 808 <p id="rfc.section.4.1.p.5">Within the header area of each body part in the multipart payload, the server <em class="bcp14">MUST</em> generate a <a href="#header.content-range" class="smpl">Content-Range</a> header field corresponding to the range being enclosed in that body part. If the selected representation would have had a <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> header field in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response, the server <em class="bcp14">SHOULD</em> generate that same <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> field in the header area of each body part. For example: 807 809 </p> 808 810 <div id="rfc.figure.u.18"></div><pre class="text">HTTP/1.1 206 Partial Content … … 823 825 ...the second range 824 826 --THIS_STRING_SEPARATES-- 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 multiple827 </pre><p id="rfc.section.4.1.p.7">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 828 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 829 the selected representation's media type and the chosen boundary parameter length, it can be less efficient to transfer many 828 830 small disjoint parts than it is to transfer the entire selected representation. 829 831 </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 not832 <p id="rfc.section.4.1.p.8">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 833 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 834 was found to be satisfiable or only one range remained after coalescing. A client that cannot process a multipart/byteranges 833 835 response <em class="bcp14">MUST NOT</em> ask for multiple ranges in a single request. 834 836 </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 that837 <p id="rfc.section.4.1.p.9">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 838 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 839 on receiving the same ranges that it requested, nor the same order that it requested. 838 840 </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.1 0">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 abovebecause the client is understood to already have841 <p id="rfc.section.4.1.p.10">When a 206 response is generated, the server <em class="bcp14">MUST</em> generate the following header fields, in addition to those required 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>. 842 </p> 843 <p id="rfc.section.4.1.p.11">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 required above, because the client is understood to already have 842 844 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. 843 845 </p> 844 <p id="rfc.section.4.1.p.1 1">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.846 <p id="rfc.section.4.1.p.12">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. 845 847 </p> 846 848 <div id="rfc.iref.c.1"></div> 847 849 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="header.content-range" href="#header.content-range">Content-Range</a></h2> 848 <p id="rfc.section.4.2.p.1">The "Content-Range" header field is sent with a partial representation to specify what range of the full representation is849 enclosed as payload.850 <p id="rfc.section.4.2.p.1">The "Content-Range" header field is sent in a single part <a href="#status.206" class="smpl">206 (Partial Content)</a> response to indicate the partial range of the selected representation enclosed as the message payload, sent in each part of 851 a multipart 206 response to indicate the range enclosed within each body part, and sent in <a href="#status.416" class="smpl">416 (Range Not Satisfiable)</a> responses to provide information about the selected representation. 850 852 </p> 851 853 <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span> <a href="#header.content-range" class="smpl">Content-Range</a> = <a href="#header.content-range" class="smpl">byte-content-range</a> … … 863 865 <a href="#header.content-range" class="smpl">other-content-range</a> = <a href="#range.units.other" class="smpl">other-range-unit</a> <a href="#imported.abnf" class="smpl">SP</a> <a href="#header.content-range" class="smpl">other-range-resp</a> 864 866 <a href="#header.content-range" class="smpl">other-range-resp</a> = *<a href="#imported.abnf" class="smpl">CHAR</a> 865 </pre><p id="rfc.section.4.2.p.3">Range units are defined in <a href="#range.units" title="Range Units">Section 2</a>. A recipient of a <a href="#status.206" class="smpl">206 (Partial Content)</a> response containing a <a href="#header.content-range" class="smpl">Content-Range</a> header field with a <a href="#range.units" class="smpl">range unit</a> that the recipient does not understand <em class="bcp14">MUST NOT</em> attempt to recombine it with a stored representation. A proxy that receives such a message <em class="bcp14">SHOULD</em> forward it downstream. 866 </p> 867 <p id="rfc.section.4.2.p.4">For byte ranges, a sender <em class="bcp14">SHOULD</em> indicate the complete length of the representation from which the range has been extracted unless the complete length is unknown 868 or difficult to determine. An asterisk character ("*") in place of the complete-length indicates that the representation length 869 was unknown when the header field was generated. 870 </p> 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. 872 </p> 873 <p id="rfc.section.4.2.p.6">A server generating a <a href="#status.206" class="smpl">206 (Partial Content)</a> response to a byte range request <em class="bcp14">MUST</em> send, in each body part of a multipart response or in the header block of a single part response, a Content-Range header field 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 875 selected representation is known by the sender to be 1234 bytes: 867 </pre><p id="rfc.section.4.2.p.3">If a <a href="#status.206" class="smpl">206 (Partial Content)</a> response contains a <a href="#header.content-range" class="smpl">Content-Range</a> header field with a <a href="#range.units" class="smpl">range unit</a> (<a href="#range.units" title="Range Units">Section 2</a>) that the recipient does not understand, the recipient <em class="bcp14">MUST NOT</em> attempt to recombine it with a stored representation. A proxy that receives such a message <em class="bcp14">SHOULD</em> forward it downstream. 868 </p> 869 <p id="rfc.section.4.2.p.4">For byte ranges, a sender <em class="bcp14">SHOULD</em> indicate the complete length of the representation from which the range has been extracted, unless the complete length is 870 unknown or difficult to determine. An asterisk character ("*") in place of the complete-length indicates that the representation 871 length was unknown when the header field was generated. 872 </p> 873 <p id="rfc.section.4.2.p.5">The following example illustrates when the complete length of the selected representation is known by the sender to be 1234 874 bytes: 876 875 </p> 877 876 <div id="rfc.figure.u.20"></div><pre class="text"> Content-Range: bytes 42-1233/1234 878 </pre><p id="rfc.section.4.2.p. 8">or this second example would applywhen the complete length is unknown:</p>877 </pre><p id="rfc.section.4.2.p.7">and this second example illustrates when the complete length is unknown:</p> 879 878 <div id="rfc.figure.u.21"></div><pre class="text"> Content-Range: bytes 42-1233/* 880 </pre><p id="rfc.section.4.2.p.10">A server generating a <a href="#status.416" class="smpl">416 (Range Not Satisfiable)</a> response to a byte range request <em class="bcp14">SHOULD</em> send a Content-Range header field with an <a href="#header.content-range" class="smpl">unsatisfied-range</a> value, as in the following example: 879 </pre><p id="rfc.section.4.2.p.9">A Content-Range field value is invalid if it contains 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. 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. 880 </p> 881 <p id="rfc.section.4.2.p.10">A server generating a <a href="#status.416" class="smpl">416 (Range Not Satisfiable)</a> response to a byte range request <em class="bcp14">SHOULD</em> send a Content-Range header field with an <a href="#header.content-range" class="smpl">unsatisfied-range</a> value, as in the following example: 881 882 </p> 882 883 <div id="rfc.figure.u.22"></div><pre class="text"> Content-Range: bytes */1234 883 </pre><p id="rfc.section.4.2.p.12">The complete-length in a 416 response indicates the current length of the selected representation, which will be known by 884 the server generating the response because that is how it determined the range to be unsatisfiable. 885 </p> 884 </pre><p id="rfc.section.4.2.p.12">The complete-length in a 416 response indicates the current length of the selected representation.</p> 886 885 <p id="rfc.section.4.2.p.13">The "Content-Range" header field has no meaning for status codes that do not explicitly describe its semantic. For this specification, 887 886 only the <a href="#status.206" class="smpl">206 (Partial Content)</a> and <a href="#status.416" class="smpl">416 (Range Not Satisfiable)</a> status codes describe a meaning for Content-Range. 888 887 </p> 889 <p id="rfc.section.4.2.p.14"> More examples of Content-Range values, assuming that therepresentation contains a total of 1234 bytes: </p>888 <p id="rfc.section.4.2.p.14">The following are examples of Content-Range values in which the selected representation contains a total of 1234 bytes: </p> 890 889 <ul> 891 890 <li>The first 500 bytes: … … 908 907 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.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>) or, if no entity-tag is provided, a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> 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.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>. 909 908 </p> 910 <p id="rfc.section.4.3.p.2">When a client receives an incomplete <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response or a <a href="#status.206" class="smpl">206 (Partial Content)</a> response, and already has one or more partial responses for the same method and effective request URI that have the same strong 911 validator as present in the new response, the recipient <em class="bcp14">MAY</em> combine some or all of those responses into a set of continuous ranges. A client <em class="bcp14">MUST NOT</em> combine responses that differ in the strong validator or that do not have a strong validator. 912 </p> 913 <p id="rfc.section.4.3.p.3">If the new response is an incomplete <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response, then the header fields of that new response are used for any combined response and replace those of the matching 914 stored responses. 915 </p> 916 <p id="rfc.section.4.3.p.4">If the new response is a <a href="#status.206" class="smpl">206 (Partial Content)</a> response and at least one of the matching stored responses is a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>, then the combined response header fields consist of the most recent 200 response's header fields. If all of the matching 909 <p id="rfc.section.4.3.p.2">A client that has received multiple partial responses to GET requests on a target resource <em class="bcp14">MAY</em> combine those responses into a larger continuous range if they share the same strong validator. 910 </p> 911 <p id="rfc.section.4.3.p.3">If the most recent response is an incomplete <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response, then the header fields of that response are used for any combined response and replace those of the matching stored 912 responses. 913 </p> 914 <p id="rfc.section.4.3.p.4">If the most recent response is a <a href="#status.206" class="smpl">206 (Partial Content)</a> response and at least one of the matching stored responses is a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>, then the combined response header fields consist of the most recent 200 response's header fields. If all of the matching 917 915 stored responses are 206 responses, then the stored response with the most recent header fields is used as the source of header 918 916 fields for the combined response, except that the client <em class="bcp14">MUST</em> use other header fields provided in the new response, aside from <a href="#header.content-range" class="smpl">Content-Range</a>, to replace all instances of the corresponding header fields in the stored response. … … 923 921 <div id="rfc.iref.29"></div> 924 922 <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a> <a id="status.416" href="#status.416">416 Range Not Satisfiable</a></h2> 925 <p id="rfc.section.4.4.p.1">The <dfn>416 (Range Not Satisfiable)</dfn> status code indicates that none of the ranges-specifier values in the request's <a href="#header.range" class="smpl">Range</a> header field (<a href="#header.range" id="rfc.xref.header.range.3" title="Range">Section 3.1</a>) overlap the current extent of the selected resource and the request did not include an <a href="#header.if-range" class="smpl">If-Range</a> header field (<a href="#header.if-range" id="rfc.xref.header.if-range.2" title="If-Range">Section 3.2</a>). (For byte-ranges, this means that the first-byte-pos of all of the byte-range-spec values were greater than the current 926 length of the selected representation.) 927 </p> 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>). 923 <p id="rfc.section.4.4.p.1">The <dfn>416 (Range Not Satisfiable)</dfn> status code indicates that none of the ranges in the request's <a href="#header.range" class="smpl">Range</a> header field (<a href="#header.range" id="rfc.xref.header.range.3" title="Range">Section 3.1</a>) overlap the current extent of the selected resource or that the set of ranges requested has been rejected due to invalid 924 ranges or an excessive request of small or overlapping ranges. 925 </p> 926 <p id="rfc.section.4.4.p.2">For byte ranges, failing to overlap the current extent means that the <a href="#rule.ranges-specifier" class="smpl">first-byte-pos</a> of all of the <a href="#rule.ranges-specifier" class="smpl">byte-range-spec</a> values were greater than the current length of the selected representation. When this status code is generated in response 927 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 (<a href="#header.content-range" id="rfc.xref.header.content-range.2" title="Content-Range">Section 4.2</a>). 929 928 </p> 930 929 <div id="rfc.figure.u.27"></div> … … 932 931 Date: Mon, 20 Jan 2012 15:41:54 GMT 933 932 Content-Range: bytes */47022 934 Content-Type: image/gif935 933 </pre><div class="note" id="rfc.section.4.4.p.4"> 936 <p> <b>Note:</b> Clients cannot depend on servers to send a <a href="#status.416" class="smpl">416 (Range Not937 Satisfiable)</a> response instead of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response for an unsatisfiable <a href="#header.range" class="smpl">Range</a> header field, since not all servers implement this header field.934 <p> <b>Note:</b> Because servers are free to ignore <a href="#header.range" class="smpl">Range</a>, many implementations will simply respond with <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> if the requested ranges are invalid or not satisfiable. That is partly because most clients are prepared to receive a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> to complete the task (albeit less efficiently) and partly because clients might not stop making an invalid partial request 935 until they have received a complete representation. Thus, clients cannot depend on receiving a <a href="#status.416" class="smpl">416 (Range Not Satisfiable)</a> response even when it is most appropriate. 938 936 </p> 939 937 </div> … … 1042 1040 <td class="left">http</td> 1043 1041 <td class="left">standard</td> 1044 <td class="left"> <a href="#header.if-range" id="rfc.xref.header.if-range. 3" title="If-Range">Section 3.2</a>1042 <td class="left"> <a href="#header.if-range" id="rfc.xref.header.if-range.2" title="If-Range">Section 3.2</a> 1045 1043 </td> 1046 1044 </tr> … … 1379 1377 </li> 1380 1378 <li><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul> 1381 <li>If-Range header field <a href="#rfc.xref.header.if-range.1">3.1</a>, <a href="#rfc.iref.i.1"><b>3.2</b></a>, <a href="#rfc.xref.header.if-range.2"> 4.4</a>, <a href="#rfc.xref.header.if-range.3">5.3</a></li>1379 <li>If-Range header field <a href="#rfc.xref.header.if-range.1">3.1</a>, <a href="#rfc.iref.i.1"><b>3.2</b></a>, <a href="#rfc.xref.header.if-range.2">5.3</a></li> 1382 1380 </ul> 1383 1381 </li> -
draft-ietf-httpbis/latest/p5-range.xml
r2157 r2158 530 530 If multiple parts are being transferred, the server generating the 206 531 531 response &MUST; generate a "multipart/byteranges" payload, as defined 532 in <xref target="internet.media.type.multipart.byteranges"/>, and senda532 in <xref target="internet.media.type.multipart.byteranges"/>, and a 533 533 <x:ref>Content-Type</x:ref> header field containing the 534 534 multipart/byteranges media type and its required boundary parameter. 535 To avoid confusion with single part responses, a server &MUST-NOT; generate 536 a <x:ref>Content-Range</x:ref> header field in the HTTP header block of a 537 multiple part response (this field will be sent in each part instead). 538 </t> 539 <t> 535 540 Within the header area of each body part in the multipart payload, the 536 541 server &MUST; generate a <x:ref>Content-Range</x:ref> header field … … 594 599 <t> 595 600 When a 206 response is generated, the server &MUST; generate the following 596 header fields, in addition to those described above, if the field would601 header fields, in addition to those required above, if the field would 597 602 have been sent in a <x:ref>200 (OK)</x:ref> response to the same request: 598 603 <x:ref>Date</x:ref>, <x:ref>Cache-Control</x:ref>, <x:ref>ETag</x:ref>, … … 603 608 If a 206 is generated in response to a request with an <x:ref>If-Range</x:ref> 604 609 header field, the sender &SHOULD-NOT; generate other representation header 605 fields beyond those described abovebecause the client is understood to610 fields beyond those required above, because the client is understood to 606 611 already have a prior response containing those header fields. 607 612 Otherwise, the sender &MUST; generate all of the representation header … … 626 631 <x:anchor-alias value="other-range-resp"/> 627 632 <t> 628 The "Content-Range" header field is sent with a partial representation to 629 specify what range of the full representation is enclosed as payload. 633 The "Content-Range" header field is sent in a single part 634 <x:ref>206 (Partial Content)</x:ref> response to indicate the partial range 635 of the selected representation enclosed as the message payload, sent in 636 each part of a multipart 206 response to indicate the range enclosed within 637 each body part, and sent in <x:ref>416 (Range Not Satisfiable)</x:ref> 638 responses to provide information about the selected representation. 630 639 </t> 631 640 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Range"/><iref primary="true" item="Grammar" subitem="byte-content-range"/><iref primary="true" item="Grammar" subitem="byte-range-resp"/><iref primary="true" item="Grammar" subitem="byte-range"/><iref primary="true" item="Grammar" subitem="unsatisfied-range"/><iref primary="true" item="Grammar" subitem="other-content-range"/><iref primary="true" item="Grammar" subitem="other-range-resp"/><iref primary="true" item="Grammar" subitem="complete-length"/> … … 646 655 </artwork></figure> 647 656 <t> 648 Range units are defined in <xref target="range.units"/>. A recipient of a 649 <x:ref>206 (Partial Content)</x:ref> response containing a 657 If a <x:ref>206 (Partial Content)</x:ref> response contains a 650 658 <x:ref>Content-Range</x:ref> header field with a <x:ref>range unit</x:ref> 651 that the recipient does not understand &MUST-NOT; attempt to recombine it652 with a stored representation. A proxy that receives such a message653 &SHOULD; forward it downstream.659 (<xref target="range.units"/>) that the recipient does not understand, the 660 recipient &MUST-NOT; attempt to recombine it with a stored representation. 661 A proxy that receives such a message &SHOULD; forward it downstream. 654 662 </t> 655 663 <t> 656 664 For byte ranges, a sender &SHOULD; indicate the complete length of the 657 representation from which the range has been extracted unless the complete665 representation from which the range has been extracted, unless the complete 658 666 length is unknown or difficult to determine. An asterisk character ("*") in 659 667 place of the complete-length indicates that the representation length was … … 661 669 </t> 662 670 <t> 663 A Content-Range field value with a <x:ref>byte-range-resp</x:ref> that has 664 a <x:ref>last-byte-pos</x:ref> value less than its 665 <x:ref>first-byte-pos</x:ref> value, or a <x:ref>complete-length</x:ref> 666 value less than or equal to its <x:ref>last-byte-pos</x:ref> value, is 667 invalid. The recipient of an invalid <x:ref>Content-Range</x:ref> &MUST-NOT; 668 attempt to recombine the received content with a stored representation. 669 </t> 670 <t> 671 A server generating a <x:ref>206 (Partial Content)</x:ref> response to a 672 byte range request &MUST; send, in each body part of a multipart response 673 or in the header block of a single part response, a Content-Range header 674 field containing a <x:ref>byte-range-resp</x:ref> value that reflects the 675 corresponding range being sent. The following example would apply 676 when the complete length of the selected representation is known by the 677 sender to be 1234 bytes: 671 The following example illustrates when the complete length of the selected 672 representation is known by the sender to be 1234 bytes: 678 673 </t> 679 674 <figure><artwork type="example"> … … 681 676 </artwork></figure> 682 677 <t> 683 or this second example would applywhen the complete length is unknown:678 and this second example illustrates when the complete length is unknown: 684 679 </t> 685 680 <figure><artwork type="example"> 686 681 Content-Range: bytes 42-1233/* 687 682 </artwork></figure> 683 <t> 684 A Content-Range field value is invalid if it contains a 685 <x:ref>byte-range-resp</x:ref> that has a <x:ref>last-byte-pos</x:ref> 686 value less than its <x:ref>first-byte-pos</x:ref> value, or a 687 <x:ref>complete-length</x:ref> value less than or equal to its 688 <x:ref>last-byte-pos</x:ref> value. The recipient of an invalid 689 <x:ref>Content-Range</x:ref> &MUST-NOT; attempt to recombine the received 690 content with a stored representation. 691 </t> 688 692 <t> 689 693 A server generating a <x:ref>416 (Range Not Satisfiable)</x:ref> response … … 696 700 <t> 697 701 The complete-length in a 416 response indicates the current length of the 698 selected representation, which will be known by the server generating the 699 response because that is how it determined the range to be unsatisfiable. 702 selected representation. 700 703 </t> 701 704 <t> … … 707 710 </t> 708 711 <t> 709 More examples of Content-Range values, assuming that the representation710 contains a total of 1234 bytes:712 The following are examples of Content-Range values in which the 713 selected representation contains a total of 1234 bytes: 711 714 <list style="symbols"> 712 715 <t> … … 751 754 </t> 752 755 <t> 753 When a client receives an incomplete <x:ref>200 (OK)</x:ref> response or a 754 <x:ref>206 (Partial Content)</x:ref> response, and already has one or more 755 partial responses for the same method and effective request URI that have 756 the same strong validator as present in the new response, 757 the recipient &MAY; combine some or all of those responses into a set of 758 continuous ranges. A client &MUST-NOT; combine responses that differ in the 759 strong validator or that do not have a strong validator. 760 </t> 761 <t> 762 If the new response is an incomplete <x:ref>200 (OK)</x:ref> response, then 763 the header fields of that new response are used for any combined response 764 and replace those of the matching stored responses. 765 </t> 766 <t> 767 If the new response is a <x:ref>206 (Partial Content)</x:ref> response and 768 at least one of the matching stored responses is a <x:ref>200 (OK)</x:ref>, 769 then the combined response header fields consist of the most recent 200 770 response's header fields. If all of the matching stored responses are 206 771 responses, then the stored response with the most recent header fields is 772 used as the source of header fields for the combined response, except that 773 the client &MUST; use other header fields provided in the new response, 774 aside from <x:ref>Content-Range</x:ref>, to replace all instances of the 775 corresponding header fields in the stored response. 756 A client that has received multiple partial responses to GET requests on a 757 target resource &MAY; combine those responses into a larger continuous 758 range if they share the same strong validator. 759 </t> 760 <t> 761 If the most recent response is an incomplete <x:ref>200 (OK)</x:ref> 762 response, then the header fields of that response are used for any 763 combined response and replace those of the matching stored responses. 764 </t> 765 <t> 766 If the most recent response is a <x:ref>206 (Partial Content)</x:ref> 767 response and at least one of the matching stored responses is a 768 <x:ref>200 (OK)</x:ref>, then the combined response header fields consist 769 of the most recent 200 response's header fields. If all of the matching 770 stored responses are 206 responses, then the stored response with the most 771 recent header fields is used as the source of header fields for the 772 combined response, except that the client &MUST; use other header fields 773 provided in the new response, aside from <x:ref>Content-Range</x:ref>, to 774 replace all instances of the corresponding header fields in the stored 775 response. 776 776 </t> 777 777 <t> … … 798 798 <x:anchor-alias value="416 (Range Not Satisfiable)"/> 799 799 <t> 800 The <x:dfn>416 (Range Not Satisfiable)</x:dfn> status code 801 indicates that none of the ranges-specifier values in the request's 802 <x:ref>Range</x:ref> header field (<xref target="header.range"/>) 803 overlap the current 804 extent of the selected resource and the request did not include an 805 <x:ref>If-Range</x:ref> header field (<xref target="header.if-range"/>). 806 (For byte-ranges, this means that the first-byte-pos of all of the 807 byte-range-spec values were greater than the current length of the selected 808 representation.) 809 </t> 810 <t> 811 When this status code is sent in response to a byte-range request, the 800 The <x:dfn>416 (Range Not Satisfiable)</x:dfn> status code indicates that 801 none of the ranges in the request's <x:ref>Range</x:ref> header field 802 (<xref target="header.range"/>) overlap the current extent of the selected 803 resource or that the set of ranges requested has been rejected due to 804 invalid ranges or an excessive request of small or overlapping ranges. 805 </t> 806 <t> 807 For byte ranges, failing to overlap the current extent means that the 808 <x:ref>first-byte-pos</x:ref> of all of the <x:ref>byte-range-spec</x:ref> 809 values were greater than the current length of the selected representation. 810 When this status code is generated in response to a byte range request, the 812 811 sender &SHOULD; generate a <x:ref>Content-Range</x:ref> header field 813 812 specifying the current length of the selected representation 814 ( see<xref target="header.content-range"/>).813 (<xref target="header.content-range"/>). 815 814 </t> 816 815 <figure> … … 820 819 Date: Mon, 20 Jan 2012 15:41:54 GMT 821 820 Content-Range: bytes */47022 822 Content-Type: image/gif823 821 </artwork></figure> 824 822 <x:note> 825 823 <t> 826 &Note; Clients cannot depend on servers to send a <x:ref>416 (Range Not 827 Satisfiable)</x:ref> response instead of a <x:ref>200 (OK)</x:ref> 828 response for an unsatisfiable <x:ref>Range</x:ref> header field, since not 829 all servers implement this header field. 824 &Note; Because servers are free to ignore <x:ref>Range</x:ref>, many 825 implementations will simply respond with <x:ref>200 (OK)</x:ref> if the 826 requested ranges are invalid or not satisfiable. That is partly because 827 most clients are prepared to receive a <x:ref>200 (OK)</x:ref> to 828 complete the task (albeit less efficiently) and partly because clients 829 might not stop making an invalid partial request until they have received 830 a complete representation. Thus, clients cannot depend on receiving a 831 <x:ref>416 (Range Not Satisfiable)</x:ref> response even when it is most 832 appropriate. 830 833 </t> 831 834 </x:note>
Note: See TracChangeset
for help on using the changeset viewer.