Changeset 994 for draft-ietf-httpbis/latest/p5-range.html

Timestamp:

Sep 7, 2010, 4:46:12 AM (9 years ago)

Author:

julian.reschke@…

Message:

Uniform use of 'header field' (see #234)

File:

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

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

@@ -400 +400 @@
       <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="2010-09-01">
+      <meta name="dct.issued" scheme="ISO8601" content="2010-09-07">
       <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, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests.">
@@ -426 +426 @@
             </tr>
             <tr>
-               <td class="left">Expires: March 5, 2011</td>
+               <td class="left">Expires: March 11, 2011</td>
                <td class="right">J. Mogul</td>
             </tr>
@@ -483 +483 @@
             <tr>
                <td class="left"></td>
-               <td class="right">September 1, 2010</td>
+               <td class="right">September 7, 2010</td>
             </tr>
          </tbody>
@@ -509 +509 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on March 5, 2011.</p>
+      <p>This Internet-Draft will expire on March 11, 2011.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -645 +645 @@
          unit defined by HTTP/1.1 is "bytes". Additional specifiers can be defined as described in <a href="#range.specifier.registry" title="Range Specifier Registry">Section&nbsp;2.1</a>.
       </p>
-      <p id="rfc.section.2.p.4">If a range unit is not understood in a request, a server <em class="bcp14">MUST</em> ignore the whole Range header (<a href="#header.range" id="rfc.xref.header.range.2" title="Range">Section&nbsp;5.4</a>). If a range unit is not understood in a response, an intermediary <em class="bcp14">SHOULD</em> pass the response to the client; a client <em class="bcp14">MUST</em> fail.
+      <p id="rfc.section.2.p.4">If a range unit is not understood in a request, a server <em class="bcp14">MUST</em> ignore the whole Range header field (<a href="#header.range" id="rfc.xref.header.range.2" title="Range">Section&nbsp;5.4</a>). If a range unit is not understood in a response, an intermediary <em class="bcp14">SHOULD</em> pass the response to the client; a client <em class="bcp14">MUST</em> fail.
       </p>
       <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="range.specifier.registry" href="#range.specifier.registry">Range Specifier Registry</a></h2>
@@ -679 +679 @@
       <p id="rfc.section.3.1.p.3">If the 206 response is the result of an If-Range request, the response <em class="bcp14">SHOULD NOT</em> include other representation header fields. Otherwise, the response <em class="bcp14">MUST</em> include all of the representation header fields that would have been returned with a 200 (OK) response to the same request.
       </p>
-      <p id="rfc.section.3.1.p.4">A cache <em class="bcp14">MUST NOT</em> combine a 206 response with other previously cached content if the ETag or Last-Modified headers do not match exactly, see <a href="#combining.byte.ranges" title="Combining Ranges">Section&nbsp;4</a>.
-      </p>
-      <p id="rfc.section.3.1.p.5">A cache that does not support the Range and Content-Range headers <em class="bcp14">MUST NOT</em> cache 206 (Partial Content) responses. Furthermore, if a response uses a range unit that is not understood by the cache, then
+      <p id="rfc.section.3.1.p.4">A cache <em class="bcp14">MUST NOT</em> combine a 206 response with other previously cached content if the ETag or Last-Modified header fields do not match exactly,
+         see <a href="#combining.byte.ranges" title="Combining Ranges">Section&nbsp;4</a>.
+      </p>
+      <p id="rfc.section.3.1.p.5">A cache that does not support the Range and Content-Range header fields <em class="bcp14">MUST NOT</em> cache 206 (Partial Content) responses. Furthermore, if a response uses a range unit that is not understood by the cache, then
          it <em class="bcp14">MUST NOT</em> be cached either.
       </p>
@@ -721 +722 @@
       </p>
       <div id="rfc.figure.u.6"></div><pre class="text">  Accept-Ranges: bytes
-</pre><p id="rfc.section.5.1.p.5">but are not required to do so. Clients <em class="bcp14">MAY</em> generate range requests without having received this header for the resource involved. Range units are defined in <a href="#range.units" title="Range Units">Section&nbsp;2</a>.
+</pre><p id="rfc.section.5.1.p.5">but are not required to do so. Clients <em class="bcp14">MAY</em> generate range requests without having received this header field for the resource involved. Range units are defined in <a href="#range.units" title="Range Units">Section&nbsp;2</a>.
       </p>
       <p id="rfc.section.5.1.p.6">Servers that do not accept any kind of range request for a resource <em class="bcp14">MAY</em> send
@@ -752 +753 @@
                              <a href="#header.content-range" class="smpl">other-range-resp-spec</a>
   <a href="#header.content-range" class="smpl">other-range-resp-spec</a>    = *<a href="#notation" class="smpl">CHAR</a>
-</pre><p id="rfc.section.5.2.p.4">The header <em class="bcp14">SHOULD</em> indicate the total length of the full representation, unless this length is unknown or difficult to determine. The asterisk
+</pre><p id="rfc.section.5.2.p.4">The header field <em class="bcp14">SHOULD</em> indicate the total length of the full representation, unless this length is unknown or difficult to determine. The asterisk
          "*" character means that the instance-length is unknown at the time when the response was generated.
       </p>
@@ -779 +780 @@
       </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
-         a request for a set of ranges that overlap without any holes), this content is transmitted with a Content-Range header, and
-         a Content-Length header showing the number of bytes actually transferred. For example,
+         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,
       </p>
       <div id="rfc.figure.u.13"></div><pre class="text">  HTTP/1.1 206 Partial Content
@@ -805 +806 @@
       <div class="note" id="rfc.section.5.2.p.16"> 
          <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 request-header, since not all servers implement this request-header.
+            an unsatisfiable Range request-header field, since not all servers implement this request-header field.
          </p> 
       </div>
@@ -812 +813 @@
       <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>
       <p id="rfc.section.5.3.p.1">If a client has a partial copy of a representation in its cache, and wishes to have an up-to-date copy of the entire representation
-         in its cache, it could use the Range request-header with a conditional GET (using either or both of If-Unmodified-Since and
-         If-Match.) However, if the condition fails because the representation has been modified, the client would then have to make
-         a second request to obtain the entire current representation.
+         in its cache, it could use the Range request-header field with a conditional GET (using either or both of If-Unmodified-Since
+         and If-Match.) However, if the condition fails because the representation has been modified, the client would then have to
+         make a second request to obtain the entire current representation.
       </p>
       <p id="rfc.section.5.3.p.2">The "If-Range" request-header field allows a client to "short-circuit" the second request. Informally, its meaning is "if
@@ -821 +822 @@
       <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span>  <a href="#header.if-range" class="smpl">If-Range</a>   = "If-Range" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.if-range" class="smpl">If-Range-v</a>
   <a href="#header.if-range" class="smpl">If-Range-v</a> = <a href="#abnf.dependencies" class="smpl">entity-tag</a> / <a href="#abnf.dependencies" class="smpl">HTTP-date</a>
-</pre><p id="rfc.section.5.3.p.4">If the client has no entity-tag for a representation, but does have a Last-Modified date, it <em class="bcp14">MAY</em> use that date in an If-Range header. (The server can distinguish between a valid HTTP-date and any form of entity-tag by examining
-         no more than two characters.) The If-Range header <em class="bcp14">SHOULD</em> only be used together with a Range header, and <em class="bcp14">MUST</em> be ignored if the request does not include a Range header, or if the server does not support the sub-range operation.
-      </p>
-      <p id="rfc.section.5.3.p.5">If the entity-tag given in the If-Range header matches the current cache validator for the representation, then the server <em class="bcp14">SHOULD</em> provide the specified sub-range of the representation using a 206 (Partial Content) response. If the cache validator does
+</pre><p id="rfc.section.5.3.p.4">If the client has no entity-tag for a representation, but does have a Last-Modified date, it <em class="bcp14">MAY</em> use that date in an If-Range header field. (The server can distinguish between a valid HTTP-date and any form of entity-tag
+         by examining no more than two characters.) The If-Range header field <em class="bcp14">SHOULD</em> only be used together with a Range header field, and <em class="bcp14">MUST</em> be ignored if the request does not include a Range header field, or if the server does not support the sub-range operation.
+      </p>
+      <p id="rfc.section.5.3.p.5">If the entity-tag given in the If-Range header field matches the current cache validator for the representation, then the
+         server <em class="bcp14">SHOULD</em> provide the specified sub-range of the representation using a 206 (Partial Content) response. If the cache validator does
          not match, then the server <em class="bcp14">SHOULD</em> return the entire representation using a 200 (OK) response.
       </p>
@@ -896 +898 @@
   <a href="#range.retrieval.requests" class="smpl">other-ranges-specifier</a> = <a href="#range.units" class="smpl">other-range-unit</a> "=" <a href="#range.retrieval.requests" class="smpl">other-range-set</a>
   <a href="#range.retrieval.requests" class="smpl">other-range-set</a> = 1*<a href="#notation" 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. However, HTTP/1.1 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 and the specified range or ranges are appropriate for the representation: </p>
-      <ul>
-         <li>The presence of a Range header in an unconditional GET modifies what is returned if the GET is otherwise successful. In other
-            words, the response carries a status code of 206 (Partial Content) instead of 200 (OK).
-         </li>
-         <li>The presence of a Range header in a conditional GET (a request using one or both of If-Modified-Since and If-None-Match, or
-            one or both of If-Unmodified-Since and If-Match) modifies what is returned if the GET is otherwise successful and the condition
+</pre><p id="rfc.section.5.4.2.p.3">A server <em class="bcp14">MAY</em> ignore the Range header field. However, HTTP/1.1 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 returned if the GET is otherwise successful.
+            In other words, the response carries a status code of 206 (Partial Content) instead of 200 (OK).
+         </li>
+         <li>The presence of a Range header field in a conditional GET (a request using one or both of If-Modified-Since and If-None-Match,
+            or one or both of If-Unmodified-Since and If-Match) modifies what is returned if the GET is otherwise successful and the condition
             is true. It does not affect the 304 (Not Modified) response returned 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 (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.
+      <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
@@ -1287 +1289 @@
       </ul>
       <h2 id="rfc.section.D.4"><a href="#rfc.section.D.4">D.4</a>&nbsp;<a id="changes.since.02" href="#changes.since.02">Since draft-ietf-httpbis-p5-range-02</a></h2>
-      <p id="rfc.section.D.4.p.1">Ongoing work on IANA Message Header Registration (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>&gt;): 
-      </p>
-      <ul>
-         <li>Reference RFC 3984, and update header registrations for headers defined in this document.</li>
+      <p id="rfc.section.D.4.p.1">Ongoing work on IANA Message Header Field Registration (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>&gt;): 
+      </p>
+      <ul>
+         <li>Reference RFC 3984, and update header field registrations for headers defined in this document.</li>
       </ul>
       <h2 id="rfc.section.D.5"><a href="#rfc.section.D.5">D.5</a>&nbsp;<a id="changes.since.03" href="#changes.since.03">Since draft-ietf-httpbis-p5-range-03</a></h2>
@@ -1304 +1306 @@
          <li>Use "/" instead of "|" for alternatives.</li>
          <li>Introduce new ABNF rules for "bad" whitespace ("BWS"), optional whitespace ("OWS") and required whitespace ("RWS").</li>
-         <li>Rewrite ABNFs to spell out whitespace rules, factor out header value format definitions.</li>
+         <li>Rewrite ABNFs to spell out whitespace rules, factor out header field value format definitions.</li>
       </ul>
       <h2 id="rfc.section.D.7"><a href="#rfc.section.D.7">D.7</a>&nbsp;<a id="changes.since.05" href="#changes.since.05">Since draft-ietf-httpbis-p5-range-05</a></h2>