Changeset 1460 for draft-ietf-httpbis

Timestamp:

27/10/11 20:13:52 (9 years ago)

Author:

ylafon@…

Message:

regen after [1459]

File:

• draft-ietf-httpbis/latest/p5-range.html (modified) (4 diffs)

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

@@ -790 +790 @@
          selected resource. A response with status code 206 (Partial Content) <em class="bcp14">MUST NOT</em> include a Content-Range field with a byte-range-resp-spec of "*".
       </p>
-      <p id="rfc.section.5.2.p.8">Examples of byte-content-range-spec values, assuming that the representation contains a total of 1234 bytes: </p>
+      <p id="rfc.section.5.2.p.8">The "Content-Range" header field has no meaning for status codes that does not explicitly describe its semantic. Currently,
+         only status codes 206 (Partial Content) and 416 (Requested range not satisfiable) describe the meaning of this header field.
+      </p>
+      <p id="rfc.section.5.2.p.9">Examples of byte-content-range-spec values, assuming that the representation contains a total of 1234 bytes: </p>
       <ul>
          <li>The first 500 bytes: 
@@ -805 +808 @@
 </pre> </li>
       </ul>
-      <p id="rfc.section.5.2.p.9">When an HTTP message includes the content of a single range (for example, a response to a request for a single range, or to
+      <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
          a request for a set of ranges that overlap without any holes), this content is transmitted with a Content-Range header field,
          and a Content-Length header field showing the number of bytes actually transferred. For example,
@@ -815 +818 @@
   Content-Length: 26012
   Content-Type: image/gif
-</pre><p id="rfc.section.5.2.p.11">When an HTTP message includes the content of multiple ranges (for example, a response to a request for multiple non-overlapping
+</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
          ranges), these are transmitted as a multipart message. The multipart media type used for this purpose is "multipart/byteranges"
          as defined in <a href="#internet.media.type.multipart.byteranges" title="Internet Media Type multipart/byteranges">Appendix&nbsp;A</a>.
       </p>
-      <p id="rfc.section.5.2.p.12">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.
-      </p>
-      <p id="rfc.section.5.2.p.13">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.
-      </p>
-      <p id="rfc.section.5.2.p.14">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
+      <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.
+      </p>
+      <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.
+      </p>
+      <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
          the full representation).
       </p>
-      <p id="rfc.section.5.2.p.15">If the server receives a request (other than one including an If-Range header field) with an unsatisfiable Range header field
+      <p id="rfc.section.5.2.p.16">If the server receives a request (other than one including an If-Range header field) with an unsatisfiable Range header field
          (that is, all of whose byte-range-spec values have a first-byte-pos value greater than the current length of the selected
          resource), it <em class="bcp14">SHOULD</em> return a response code of 416 (Requested range not satisfiable) (<a href="#status.416" id="rfc.xref.status.416.1" title="416 Requested Range Not Satisfiable">Section&nbsp;3.2</a>).
       </p>
-      <div class="note" id="rfc.section.5.2.p.16"> 
+      <div class="note" id="rfc.section.5.2.p.17"> 
          <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
             an unsatisfiable Range header field, since not all servers implement this header field.
@@ -1425 +1428 @@
          </li>
          <li> &lt;<a href="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/319">http://trac.tools.ietf.org/wg/httpbis/trac/ticket/319</a>&gt;: "case sensitivity of ranges in p5"
+         </li>
+         <li> &lt;<a href="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/301">http://trac.tools.ietf.org/wg/httpbis/trac/ticket/301</a>&gt;: "Content-Range on responses other than 206"
          </li>
       </ul>