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

Timestamp:

22/07/10 09:10:39 (12 years ago)

Author:

fielding@…

Message:

regenerate html

File:

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

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

@@ -681 +681 @@
          the same entity-body.
       </p>
-      <p id="rfc.section.4.p.2">If a cache has a stored non-empty set of subranges for an entity, and an incoming response transfers another subrange, the
-         cache <em class="bcp14">MAY</em> combine the new subrange with the existing set if both the following conditions are met: 
+      <p id="rfc.section.4.p.2">If a cache has a stored non-empty set of subranges for a representation, and an incoming response transfers another subrange,
+         the cache <em class="bcp14">MAY</em> combine the new subrange with the existing set if both the following conditions are met: 
       </p>
       <ul>
@@ -695 +695 @@
       <p id="rfc.section.5.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to range requests and partial responses.</p>
       <p id="rfc.section.5.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who
-         receives the entity.
+         receives the message.
       </p>
       <div id="rfc.iref.a.1"></div>
@@ -747 +747 @@
          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.7">Examples of byte-content-range-spec values, assuming that the entity contains a total of 1234 bytes: </p>
+      <p id="rfc.section.5.2.p.7">Examples of byte-content-range-spec values, assuming that the representation contains a total of 1234 bytes: </p>
       <ul>
          <li>The first 500 bytes: 
@@ -797 +797 @@
       <p id="rfc.section.5.3.p.1">If a client has a partial copy of an entity in its cache, and wishes to have an up-to-date copy of the entire entity 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 entity has been modified, the client would then have to make a second request
-         to obtain the entire current entity-body.
+         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
-         the entity is unchanged, send me the part(s) that I am missing; otherwise, send me the entire new entity".
+         the representation is unchanged, send me the part(s) that I am missing; otherwise, send me the entire new representation".
       </p>
       <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 an entity, 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
+</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 entity, then the server <em class="bcp14">SHOULD</em> provide the specified sub-range of the entity using a 206 (Partial Content) response. If the cache validator does not match,
-         then the server <em class="bcp14">SHOULD</em> return the entire entity using a 200 (OK) response.
+      <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
+         not match, then the server <em class="bcp14">SHOULD</em> return the entire representation using a 200 (OK) response.
       </p>
       <div id="rfc.iref.r.1"></div>
@@ -815 +815 @@
       <h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a>&nbsp;<a id="header.range" href="#header.range">Range</a></h2>
       <h3 id="rfc.section.5.4.1"><a href="#rfc.section.5.4.1">5.4.1</a>&nbsp;<a id="byte.ranges" href="#byte.ranges">Byte Ranges</a></h3>
-      <p id="rfc.section.5.4.1.p.1">Since all HTTP entities are represented in HTTP messages as sequences of bytes, the concept of a byte range is meaningful
-         for any HTTP entity. (However, not all clients and servers need to support byte-range operations.)
-      </p>
-      <p id="rfc.section.5.4.1.p.2">Byte range specifications in HTTP apply to the sequence of bytes in the entity-body (not necessarily the same as the message-body).</p>
+      <p id="rfc.section.5.4.1.p.1">Since all HTTP representations are transferred as sequences of bytes, the concept of a byte range is meaningful for any HTTP
+         representation. (However, not all clients and servers need to support byte-range operations.)
+      </p>
+      <p id="rfc.section.5.4.1.p.2">Byte range specifications in HTTP apply to the sequence of bytes in the representation body (not necessarily the same as the
+         message-body).
+      </p>
       <div id="rule.ranges-specifier">
-         <p id="rfc.section.5.4.1.p.3">                A byte range operation <em class="bcp14">MAY</em> specify a single range of bytes, or a set of ranges within a single entity.
+         <p id="rfc.section.5.4.1.p.3">                A byte range operation <em class="bcp14">MAY</em> specify a single range of bytes, or a set of ranges within a single representation.
          </p>
       </div>
@@ -835 +837 @@
          recipient of a byte-range-set that includes one or more syntactically invalid byte-range-spec values <em class="bcp14">MUST</em> ignore the header field that includes that byte-range-set.
       </p>
-      <p id="rfc.section.5.4.1.p.7">If the last-byte-pos value is absent, or if the value is greater than or equal to the current length of the entity-body, last-byte-pos
-         is taken to be equal to one less than the current length of the entity-body in bytes.
-      </p>
-      <p id="rfc.section.5.4.1.p.8">By its choice of last-byte-pos, a client can limit the number of bytes retrieved without knowing the size of the entity.</p>
+      <p id="rfc.section.5.4.1.p.7">If the last-byte-pos value is absent, or if the value is greater than or equal to the current length of the representation
+         body, last-byte-pos is taken to be equal to one less than the current length of the representation in bytes.
+      </p>
+      <p id="rfc.section.5.4.1.p.8">By its choice of last-byte-pos, a client can limit the number of bytes retrieved without knowing the size of the representation.</p>
       <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span>  <a href="#rule.ranges-specifier" class="smpl">suffix-byte-range-spec</a> = "-" <a href="#rule.ranges-specifier" class="smpl">suffix-length</a>
   <a href="#rule.ranges-specifier" class="smpl">suffix-length</a> = 1*<a href="#notation" class="smpl">DIGIT</a>
-</pre><p id="rfc.section.5.4.1.p.10">A suffix-byte-range-spec is used to specify the suffix of the entity-body, of a length given by the suffix-length value. (That
-         is, this form specifies the last N bytes of an entity-body.) If the entity is shorter than the specified suffix-length, the
-         entire entity-body is used.
+</pre><p id="rfc.section.5.4.1.p.10">A suffix-byte-range-spec is used to specify the suffix of the representation body, of a length given by the suffix-length
+         value. (That is, this form specifies the last N bytes of an entity-body.) If the representation is shorter than the specified
+         suffix-length, the entire representation is used.
       </p>
       <p id="rfc.section.5.4.1.p.11">If a syntactically valid byte-range-set includes at least one byte-range-spec whose first-byte-pos is less than the current
          length of the entity-body, or at least one suffix-byte-range-spec with a non-zero suffix-length, then the byte-range-set is
-         satisfiable. Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set is unsatisfiable, the server <em class="bcp14">SHOULD</em> return a response with a status of 416 (Requested range not satisfiable). Otherwise, the server <em class="bcp14">SHOULD</em> return a response with a status of 206 (Partial Content) containing the satisfiable ranges of the entity-body.
+         satisfiable. Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set is unsatisfiable, the server <em class="bcp14">SHOULD</em> return a response with a status of 416 (Requested range not satisfiable). Otherwise, the server <em class="bcp14">SHOULD</em> return a response with a status of 206 (Partial Content) containing the satisfiable ranges of the representation.
       </p>
       <p id="rfc.section.5.4.1.p.12">Examples of byte-ranges-specifier values (assuming an entity-body of length 10000): </p>
@@ -871 +873 @@
       <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" request-header field defines the GET method (conditional or not) to request one or more sub-ranges of the response
-         entity-body, instead of the entire entity body.
+         representation body, instead of the entire representation body.
       </p>
       <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.23"></span>  <a href="#range.retrieval.requests" class="smpl">Range</a>   = "Range" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#range.retrieval.requests" class="smpl">Range-v</a>
@@ -1139 +1141 @@
 </pre> <p id="rfc.section.A.p.7">Notes: </p>
       <ol>
-         <li>Additional CRLFs may precede the first boundary string in the entity.</li>
+         <li>Additional CRLFs may precede the first boundary string in the body.</li>
          <li>Although <a href="#RFC2046" id="rfc.xref.RFC2046.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> permits the boundary string to be quoted, some existing implementations handle a quoted boundary string incorrectly.
          </li>