Changeset 2134 for draft-ietf-httpbis/latest

Timestamp:

19/01/13 21:56:25 (10 years ago)

Author:

fielding@…

Message:

(editorial) fixes for p5 feedback and simpler prose

Location:

draft-ietf-httpbis/latest

Files:

• p5-range.html (modified) (15 diffs)
• p5-range.xml (modified) (8 diffs)

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires July 21, 2013"; 
+       content: "Expires July 23, 2013"; 
   } 
   @bottom-right {
@@ -493 +493 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2013-01-17">
+      <meta name="dct.issued" scheme="ISO8601" content="2013-01-19">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests.">
@@ -519 +519 @@
             </tr>
             <tr>
-               <td class="left">Expires: July 21, 2013</td>
+               <td class="left">Expires: July 23, 2013</td>
                <td class="right">J. Reschke, Editor</td>
             </tr>
@@ -528 +528 @@
             <tr>
                <td class="left"></td>
-               <td class="right">January 17, 2013</td>
+               <td class="right">January 19, 2013</td>
             </tr>
          </tbody>
@@ -553 +553 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on July 21, 2013.</p>
+      <p>This Internet-Draft will expire on July 23, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -585 +585 @@
             </ul>
          </li>
-         <li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4">Responses to a Range Request</a><ul>
+         <li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#range.response">Responses to a Range Request</a><ul>
                <li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.1">Response to a Single and Multiple Ranges Request</a></li>
                <li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#combining.byte.ranges">Combining Ranges</a></li>
@@ -714 +714 @@
          </p> 
       </div>
-      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;Responses to a Range Request
-      </h1>
+      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="range.response" href="#range.response">Responses to a Range Request</a></h1>
       <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;Response to a Single and Multiple Ranges Request
       </h2>
@@ -823 +822 @@
 </pre> </li>
       </ul>
-      <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 might be seen as a denial-of-service
-         attack), the server <em class="bcp14">SHOULD</em> treat the request as if the invalid <a href="#range.retrieval.requests" class="smpl">Range</a> header field did not exist. (Normally, this means send a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response containing the full representation).
-      </p>
       <div id="rfc.iref.i.1"></div>
       <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a>&nbsp;<a id="header.if-range" href="#header.if-range">If-Range</a></h2>
@@ -832 +828 @@
          request to obtain the entire current representation.
       </p>
-      <p id="rfc.section.5.3.p.2">The "If-Range" header field allows a client to "short-circuit" the second request. Informally, its meaning is "if the representation
-         is unchanged, send me the part(s) that I am missing; otherwise, send me the entire new representation".
+      <p id="rfc.section.5.3.p.2">The "If-Range" header field allows a client to "short-circuit" the second request. Informally, its meaning is: if the representation
+         is unchanged, send me the part(s) that I am requesting in Range; otherwise, send me the entire representation.
       </p>
       <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.10"></span>  <a href="#header.if-range" class="smpl">If-Range</a> = <a href="#imported.abnf" class="smpl">entity-tag</a> / <a href="#imported.abnf" class="smpl">HTTP-date</a>
@@ -909 +905 @@
       </ul>
       <h3 id="rfc.section.5.4.2"><a href="#rfc.section.5.4.2">5.4.2</a>&nbsp;<a id="range.retrieval.requests" href="#range.retrieval.requests">Range Retrieval Requests</a></h3>
-      <p id="rfc.section.5.4.2.p.1">The "Range" header field defines the GET method (conditional or not) to request one or more sub-ranges of the response representation
-         data, instead of the entire representation data.
+      <p id="rfc.section.5.4.2.p.1">The "Range" header field on a GET request modifies the method semantics to request transfer of only one or more sub-ranges
+         of the selected representation data in a successful response, rather than the entire representation data.
       </p>
       <div id="rfc.figure.u.21"></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>
@@ -916 +912 @@
   <a href="#range.retrieval.requests" class="smpl">other-range-set</a> = 1*<a href="#imported.abnf" class="smpl">CHAR</a>
 </pre><p id="rfc.section.5.4.2.p.3">A server <em class="bcp14">MAY</em> ignore the Range header field. However, origin servers and intermediate caches ought to support byte ranges when possible,
-         since Range supports efficient recovery from partially failed transfers, and supports efficient partial retrieval of large
-         representations.
-      </p>
-      <p id="rfc.section.5.4.2.p.4">If the server supports the Range header field and the specified range or ranges are appropriate for the representation: </p>
-      <ul>
-         <li>The presence of a Range header field in an unconditional GET modifies what is sent if the GET is otherwise successful. In
-            other words, the response carries a status code of <a href="#status.206" class="smpl">206 (Partial Content)</a> instead of <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>.
-         </li>
-         <li>The presence of a Range header field in a conditional GET (a request using one or both of <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a> and <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a>, or one or both of <a href="p4-conditional.html#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> and <a href="p4-conditional.html#header.if-match" class="smpl">If-Match</a>) modifies what is sent if the GET is otherwise successful and the condition is true. It does not affect the <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response sent if the conditional is false.
-         </li>
-      </ul>
-      <p id="rfc.section.5.4.2.p.5">In some cases, it might be more appropriate to use the If-Range header field (see <a href="#header.if-range" id="rfc.xref.header.if-range.3" title="If-Range">Section&nbsp;5.3</a>) in addition to the Range header field.
-      </p>
-      <p id="rfc.section.5.4.2.p.6">If a proxy that supports ranges receives a Range request, forwards the request to an inbound server, and receives an entire
-         representation in reply, it <em class="bcp14">MAY</em> only send the requested range to its client.
+         since Range supports efficient recovery from partially failed transfers and partial retrieval of large representations. A
+         server <em class="bcp14">MUST</em> ignore a Range header field received with a request method other than GET.
+      </p>
+      <p id="rfc.section.5.4.2.p.4">The Range header field is evaluated after evaluating the preconditions of <a href="#Part4" id="rfc.xref.Part4.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a> and only if the result of their evaluation is leading toward a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response. In other words, Range is ignored when a conditional GET would result in a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response.
+      </p>
+      <p id="rfc.section.5.4.2.p.5">The If-Range header field (<a href="#header.if-range" id="rfc.xref.header.if-range.3" title="If-Range">Section&nbsp;5.3</a>) can be used as a precondition to applying the Range header field.
+      </p>
+      <p id="rfc.section.5.4.2.p.6">If all of the preconditions are true, the server supports the Range header field for the target resource, the specified range(s)
+         are syntactically correct (as defined in <a href="#byte.ranges" title="Byte Ranges">Section&nbsp;5.4.1</a>), and at least one of the ranges has a non-empty intersection with the current selected representation extent, then the server <em class="bcp14">MAY</em> respond with a status code of <a href="#status.206" class="smpl">206 (Partial Content)</a> and a payload containing one or more partial representations that correspond to those requested, as defined in <a href="#range.response" title="Responses to a Range Request">Section&nbsp;4</a>.
       </p>
       <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
@@ -1184 +1174 @@
   Date: Wed, 15 Nov 1995 06:25:24 GMT
   Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
-  Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
+  Content-Length: 1741
+  Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
   
   --THIS_STRING_SEPARATES
-  Content-type: application/pdf
-  Content-range: bytes 500-999/8000
+  Content-Type: application/pdf
+  Content-Range: bytes 500-999/8000
   
   ...the first range...
   --THIS_STRING_SEPARATES
-  Content-type: application/pdf
-  Content-range: bytes 7000-7999/8000
+  Content-Type: application/pdf
+  Content-Range: bytes 7000-7999/8000
   
   ...the second range
@@ -1201 +1192 @@
   Date: Tue, 14 Nov 1995 06:25:24 GMT
   Last-Modified: Tue, 14 July 04:58:08 GMT
-  Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
+  Content-Length: 2331785
+  Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
   
   --THIS_STRING_SEPARATES
-  Content-type: video/example
-  Content-range: exampleunit 1.2-4.3/25
+  Content-Type: video/example
+  Content-Range: exampleunit 1.2-4.3/25
   
   ...the first range...
   --THIS_STRING_SEPARATES
-  Content-type: video/example
-  Content-range: exampleunit 11.2-14.3/25
+  Content-Type: video/example
+  Content-Range: exampleunit 11.2-14.3/25
   
   ...the second range
@@ -1248 +1240 @@
 </pre><p id="rfc.section.C.p.5">The rules below are defined in other parts:</p>
       <div id="rfc.figure.u.25"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">HTTP-date</a>  = &lt;HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 7.1.1.1</a>&gt;
-  <a href="#imported.abnf" class="smpl">entity-tag</a> = &lt;entity-tag, defined in <a href="#Part4" id="rfc.xref.Part4.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a>&gt;
+  <a href="#imported.abnf" class="smpl">entity-tag</a> = &lt;entity-tag, defined in <a href="#Part4" id="rfc.xref.Part4.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a>&gt;
 </pre><h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
       <div id="rfc.figure.u.26"></div> <pre class="inline"><a href="#header.accept-ranges" class="smpl">Accept-Ranges</a> = acceptable-ranges
@@ -1399 +1391 @@
                      </ul>
                   </li>
-                  <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">4.2</a>, <a href="#rfc.xref.Part4.2">4.2</a>, <a href="#rfc.xref.Part4.3">5.3</a>, <a href="#rfc.xref.Part4.4">5.3</a>, <a href="#Part4"><b>9.1</b></a>, <a href="#rfc.xref.Part4.5">C</a><ul>
+                  <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">4.2</a>, <a href="#rfc.xref.Part4.2">4.2</a>, <a href="#rfc.xref.Part4.3">5.3</a>, <a href="#rfc.xref.Part4.4">5.3</a>, <a href="#rfc.xref.Part4.5">5.4.2</a>, <a href="#Part4"><b>9.1</b></a>, <a href="#rfc.xref.Part4.6">C</a><ul>
                         <li><em>Section 2.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.2">4.2</a>, <a href="#rfc.xref.Part4.3">5.3</a>, <a href="#rfc.xref.Part4.4">5.3</a></li>
-                        <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">4.2</a>, <a href="#rfc.xref.Part4.5">C</a></li>
+                        <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">4.2</a>, <a href="#rfc.xref.Part4.6">C</a></li>
                      </ul>
                   </li>

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

@@ -325 +325 @@
 </section>
 
-<section title="Responses to a Range Request">
+<section title="Responses to a Range Request" anchor="range.response">
 <section title="Response to a Single and Multiple Ranges Request">
 <t>
@@ -564 +564 @@
    </list>
 </t>
-<t>
-   If the server ignores a byte-range-spec (for example if it is
-   syntactically invalid, or if it might be seen as a denial-of-service
-   attack), the server &SHOULD; treat the request as if the invalid <x:ref>Range</x:ref>
-   header field did not exist. (Normally, this means send a <x:ref>200 (OK)</x:ref>
-   response containing the full representation).
-</t>
 </section>
 
@@ -587 +580 @@
 <t>
    The "If-Range" header field allows a client to "short-circuit" the second
-   request. Informally, its meaning is "if the representation is unchanged, send
-   me the part(s) that I am missing; otherwise, send me the entire new
-   representation".
+   request. Informally, its meaning is: if the representation is unchanged,
+   send me the part(s) that I am requesting in Range; otherwise, send me the
+   entire representation.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Range"/>
@@ -621 +614 @@
    validator for the selected representation of the target resource, then
    the server &SHOULD; send the specified sub-range of the representation
-   using a <x:ref>206 (Partial Content)</x:ref> response. If the validator does not match,
-   then the server &SHOULD; send the entire representation using a <x:ref>200 (OK)</x:ref>
-   response.
+   using a <x:ref>206 (Partial Content)</x:ref> response. If the validator
+   does not match, then the server &SHOULD; send the entire representation
+   using a <x:ref>200 (OK)</x:ref> response.
 </t>
 </section>
@@ -757 +750 @@
   <x:anchor-alias value="other-range-set"/>
 <t>
-   The "Range" header field defines the GET method (conditional or
-   not) to request one or more sub-ranges of the response representation data, instead
-   of the entire representation data.
+   The "Range" header field on a GET request modifies the method semantics to
+   request transfer of only one or more sub-ranges of the selected
+   representation data in a successful response, rather than the entire
+   representation data.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Range"/>
@@ -767 +761 @@
 </artwork></figure>
 <t>
-   A server &MAY; ignore the Range header field. However, origin
-   servers and intermediate caches ought to support byte ranges when
-   possible, since Range supports efficient recovery from partially
-   failed transfers, and supports efficient partial retrieval of large
-   representations.
-</t>
-<t>
-   If the server supports the Range header field and the specified range or
-   ranges are appropriate for the representation:
-  <list style="symbols">
-     <t>The presence of a Range header field in an unconditional GET modifies
-        what is sent if the GET is otherwise successful. In other
-        words, the response carries a status code of <x:ref>206 (Partial Content)</x:ref>
-        instead of <x:ref>200 (OK)</x:ref>.</t>
-
-     <t>The presence of a Range header field in a conditional GET (a request
-        using one or both of <x:ref>If-Modified-Since</x:ref> and
-        <x:ref>If-None-Match</x:ref>, or one or both of
-        <x:ref>If-Unmodified-Since</x:ref> and <x:ref>If-Match</x:ref>) modifies
-        what is sent if the GET is otherwise successful and the
-        condition is true. It does not affect the <x:ref>304 (Not Modified)</x:ref>
-        response sent if the conditional is false.</t>
-  </list>
-</t>
-<t>
-   In some cases, it might be more appropriate to use the If-Range
-   header field (see <xref target="header.if-range"/>) in addition to the Range
-   header field.
-</t>
-<t>
-   If a proxy that supports ranges receives a Range request, forwards 
-   the request to an inbound server, and receives an entire representation in
-   reply, it &MAY; only send the requested range to its client. 
+   A server &MAY; ignore the Range header field. However, origin servers and
+   intermediate caches ought to support byte ranges when possible, since Range
+   supports efficient recovery from partially failed transfers and partial
+   retrieval of large representations. A server &MUST; ignore a Range header
+   field received with a request method other than GET.
+</t>
+<t>
+   The Range header field is evaluated after evaluating the preconditions of
+   <xref target="Part4"/> and only if the result of their evaluation is
+   leading toward a <x:ref>200 (OK)</x:ref> response. In other words, Range
+   is ignored when a conditional GET would result in a
+   <x:ref>304 (Not Modified)</x:ref> response.
+</t>
+<t>
+   The If-Range header field (<xref target="header.if-range"/>) can be used as
+   a precondition to applying the Range header field.
+</t>
+<t>
+   If all of the preconditions are true, the server supports the Range header
+   field for the target resource, the specified range(s) are syntactically
+   correct (as defined in <xref target="byte.ranges"/>), and at least one of
+   the ranges has a non-empty intersection with the current selected
+   representation extent, then the server &MAY; respond with a status code of
+   <x:ref>206 (Partial Content)</x:ref> and a payload containing one or more
+   partial representations that correspond to those requested, as defined in
+   <xref target="range.response"/>.
 </t>
 </section>
@@ -1252 +1239 @@
   Date: Wed, 15 Nov 1995 06:25:24 GMT
   Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
-  Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
+  Content-Length: 1741
+  Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
   
   --THIS_STRING_SEPARATES
-  Content-type: application/pdf
-  Content-range: bytes 500-999/8000
+  Content-Type: application/pdf
+  Content-Range: bytes 500-999/8000
   
   ...the first range...
   --THIS_STRING_SEPARATES
-  Content-type: application/pdf
-  Content-range: bytes 7000-7999/8000
+  Content-Type: application/pdf
+  Content-Range: bytes 7000-7999/8000
   
   ...the second range
@@ -1273 +1261 @@
   Date: Tue, 14 Nov 1995 06:25:24 GMT
   Last-Modified: Tue, 14 July 04:58:08 GMT
-  Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
+  Content-Length: 2331785
+  Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
   
   --THIS_STRING_SEPARATES
-  Content-type: video/example
-  Content-range: exampleunit 1.2-4.3/25
+  Content-Type: video/example
+  Content-Range: exampleunit 1.2-4.3/25
   
   ...the first range...
   --THIS_STRING_SEPARATES
-  Content-type: video/example
-  Content-range: exampleunit 11.2-14.3/25
+  Content-Type: video/example
+  Content-Range: exampleunit 11.2-14.3/25
   
   ...the second range