Changeset 2158 for draft-ietf-httpbis


Ignore:
Timestamp:
24/01/13 15:04:10 (9 years ago)
Author:
fielding@…
Message:

Require that Content-Range not be generated in the HTTP header block
of a multiple part 206 response; addresses #405

Finish editorial cleanup of p5.

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

Legend:

Unmodified
Added
Removed

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

    r2157 r2158  
    803803
    804804... 26012 bytes of partial image data ...
    805 </pre><p id="rfc.section.4.1.p.4">If multiple parts are being transferred, the server generating the 206 response <em class="bcp14">MUST</em> generate a "multipart/byteranges" payload, as defined in <a href="#internet.media.type.multipart.byteranges" title="Internet Media Type multipart/byteranges">Appendix&nbsp;A</a>, and send a <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> header field containing the multipart/byteranges media type and its required boundary parameter. Within the header area of
    806          each body part in the multipart payload, the server <em class="bcp14">MUST</em> generate a <a href="#header.content-range" class="smpl">Content-Range</a> header field corresponding to the range being enclosed in that body part. If the selected representation would have had a <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> header field in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response, the server <em class="bcp14">SHOULD</em> generate that same <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> field in the header area of each body part. For example:
     805</pre><p id="rfc.section.4.1.p.4">If multiple parts are being transferred, the server generating the 206 response <em class="bcp14">MUST</em> generate a "multipart/byteranges" payload, as defined in <a href="#internet.media.type.multipart.byteranges" title="Internet Media Type multipart/byteranges">Appendix&nbsp;A</a>, and 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:
    807809      </p>
    808810      <div id="rfc.figure.u.18"></div><pre class="text">HTTP/1.1 206 Partial Content
    … …  
    823825...the second range
    824826--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 multiple
     827</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
    826828         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
    827829         the selected representation's media type and the chosen boundary parameter length, it can be less efficient to transfer many
    828830         small disjoint parts than it is to transfer the entire selected representation.
    829831      </p>
    830       <p id="rfc.section.4.1.p.7">A server <em class="bcp14">MUST NOT</em> generate a multipart response to a request for a single range, since a client that does not request multiple parts might not
     832      <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
    831833         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
    832834         was found to be satisfiable or only one range remained after coalescing. A client that cannot process a multipart/byteranges
    833835         response <em class="bcp14">MUST NOT</em> ask for multiple ranges in a single request.
    834836      </p>
    835       <p id="rfc.section.4.1.p.8">When a multipart response payload is generated, the server <em class="bcp14">SHOULD</em> send the parts in the same order that the corresponding byte-range-spec appeared in the received <a href="#header.range" class="smpl">Range</a> header field, excluding those ranges that were deemed unsatisfiable or that were coalesced into other ranges. A client that
     837      <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
    836838         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
    837839         on receiving the same ranges that it requested, nor the same order that it requested.
    838840      </p>
    839       <p id="rfc.section.4.1.p.9">When a 206 response is generated, the server <em class="bcp14">MUST</em> generate the following header fields, in addition to those described above, if the field would have been sent in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request: <a href="p2-semantics.html#header.date" class="smpl">Date</a>, <a href="p6-cache.html#header.cache-control" class="smpl">Cache-Control</a>, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a>, <a href="p6-cache.html#header.expires" class="smpl">Expires</a>, <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a>, and <a href="p2-semantics.html#header.vary" class="smpl">Vary</a>.
    840       </p>
    841       <p id="rfc.section.4.1.p.10">If a 206 is generated in response to a request with an <a href="#header.if-range" class="smpl">If-Range</a> header field, the sender <em class="bcp14">SHOULD NOT</em> generate other representation header fields beyond those described above because the client is understood to already have
     841      <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
    842844         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.
    843845      </p>
    844       <p id="rfc.section.4.1.p.11">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to determine freshness for 206 responses.
     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.
    845847      </p>
    846848      <div id="rfc.iref.c.1"></div>
    847849      <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<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 is
    849          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.
    850852      </p>
    851853      <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>
    … …  
    863865  <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>
    864866  <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&nbsp;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&nbsp;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:
    876875      </p>
    877876      <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 apply when 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>
    879878      <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:
    881882      </p>
    882883      <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>
    886885      <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,
    887886         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.
    888887      </p>
    889       <p id="rfc.section.4.2.p.14">More examples of Content-Range values, assuming that the representation 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>
    890889      <ul>
    891890         <li>The first 500 bytes:
    … …  
    908907         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>.
    909908      </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
    917915         stored responses are 206 responses, then the stored response with the most recent header fields is used as the source of header
    918916         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.
    … …  
    923921      <div id="rfc.iref.29"></div>
    924922      <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a>&nbsp;<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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;4.2</a>).
    929928      </p>
    930929      <div id="rfc.figure.u.27"></div>
    … …  
    932931Date: Mon, 20 Jan 2012 15:41:54 GMT
    933932Content-Range: bytes */47022
    934 Content-Type: image/gif
    935933</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 Not
    937                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.
    938936         </p>
    939937      </div>
    … …  
    10421040                  <td class="left">http</td>
    10431041                  <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&nbsp;3.2</a>
     1042                  <td class="left"> <a href="#header.if-range" id="rfc.xref.header.if-range.2" title="If-Range">Section&nbsp;3.2</a>
    10451043                  </td>
    10461044               </tr>
    … …  
    13791377            </li>
    13801378            <li><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul>
    1381                   <li>If-Range header field&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    13821380               </ul>
    13831381            </li>

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

    r2157 r2158  
    530530   If multiple parts are being transferred, the server generating the 206
    531531   response &MUST; generate a "multipart/byteranges" payload, as defined
    532    in <xref target="internet.media.type.multipart.byteranges"/>, and send a
     532   in <xref target="internet.media.type.multipart.byteranges"/>, and a
    533533   <x:ref>Content-Type</x:ref> header field containing the
    534534   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>
    535540   Within the header area of each body part in the multipart payload, the
    536541   server &MUST; generate a <x:ref>Content-Range</x:ref> header field
    … …  
    594599<t>
    595600   When a 206 response is generated, the server &MUST; generate the following
    596    header fields, in addition to those described above, if the field would
     601   header fields, in addition to those required above, if the field would
    597602   have been sent in a <x:ref>200 (OK)</x:ref> response to the same request:
    598603   <x:ref>Date</x:ref>, <x:ref>Cache-Control</x:ref>, <x:ref>ETag</x:ref>,
    … …  
    603608   If a 206 is generated in response to a request with an <x:ref>If-Range</x:ref>
    604609   header field, the sender &SHOULD-NOT; generate other representation header
    605    fields beyond those described above because the client is understood to
     610   fields beyond those required above, because the client is understood to
    606611   already have a prior response containing those header fields.
    607612   Otherwise, the sender &MUST; generate all of the representation header
    … …  
    626631  <x:anchor-alias value="other-range-resp"/>
    627632<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.
    630639</t>
    631640<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"/>
    … …  
    646655</artwork></figure>
    647656<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
    650658   <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 it
    652    with a stored representation. A proxy that receives such a message
    653    &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.
    654662</t>
    655663<t>
    656664   For byte ranges, a sender &SHOULD; indicate the complete length of the
    657    representation from which the range has been extracted unless the complete
     665   representation from which the range has been extracted, unless the complete
    658666   length is unknown or difficult to determine. An asterisk character ("*") in
    659667   place of the complete-length indicates that the representation length was
    … …  
    661669</t>
    662670<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:
    678673</t>
    679674<figure><artwork type="example">
    … …  
    681676</artwork></figure>
    682677<t>
    683    or this second example would apply when the complete length is unknown:
     678   and this second example illustrates when the complete length is unknown:
    684679</t>
    685680<figure><artwork type="example">
    686681  Content-Range: bytes 42-1233/*
    687682</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>
    688692<t>
    689693   A server generating a <x:ref>416 (Range Not Satisfiable)</x:ref> response
    … …  
    696700<t>
    697701   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.
    700703</t>
    701704<t>
    … …  
    707710</t>
    708711<t>
    709    More examples of Content-Range values, assuming that the representation
    710    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:
    711714   <list style="symbols">
    712715      <t>
    … …  
    751754</t>
    752755<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.
    776776</t>
    777777<t>
    … …  
    798798  <x:anchor-alias value="416 (Range Not Satisfiable)"/>
    799799<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
    812811   sender &SHOULD; generate a <x:ref>Content-Range</x:ref> header field
    813812   specifying the current length of the selected representation
    814    (see <xref target="header.content-range"/>).
     813   (<xref target="header.content-range"/>).
    815814</t>
    816815<figure>
    … …  
    820819Date: Mon, 20 Jan 2012 15:41:54 GMT
    821820Content-Range: bytes */47022
    822 Content-Type: image/gif
    823821</artwork></figure>
    824822<x:note>
    825823  <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.
    830833  </t>
    831834</x:note>
Note: See TracChangeset for help on using the changeset viewer.