Changeset 698 for draft-ietf-httpbis/latest/p6-cache.html

Timestamp:

26/09/09 10:09:09 (13 years ago)

Author:

julian.reschke@…

Message:

editorial: enhance readability of header introductions

File:

• draft-ietf-httpbis/latest/p6-cache.html (modified) (7 diffs)

draft-ietf-httpbis/latest/p6-cache.html

@@ -398 +398 @@
       <meta name="DC.Creator" content="Reschke, J. F.">
       <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
-      <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-25">
+      <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-26">
       <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616">
       <meta name="DC.Description.Abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document is Part 6 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
@@ -430 +430 @@
          </tr>
          <tr>
-            <td class="header left">Expires: March 29, 2010</td>
+            <td class="header left">Expires: March 30, 2010</td>
             <td class="header right">HP</td>
          </tr>
@@ -487 +487 @@
          <tr>
             <td class="header left"></td>
-            <td class="header right">September 25, 2009</td>
+            <td class="header right">September 26, 2009</td>
          </tr>
       </table>
@@ -511 +511 @@
       <p>The list of Internet-Draft Shadow Directories can be accessed at &lt;<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>&gt;.
       </p>
-      <p>This Internet-Draft will expire in March 29, 2010.</p>
+      <p>This Internet-Draft will expire in March 30, 2010.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2009 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -974 +974 @@
       <div id="rfc.iref.h.2"></div>
       <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="header.age" href="#header.age">Age</a></h2>
-      <p id="rfc.section.3.1.p.1">The "Age" response-header field conveys the sender's estimate of the amount of time since the response (or its validation)
-         was generated at the origin server. Age values are calculated as specified in <a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>.
+      <p id="rfc.section.3.1.p.1">The "Age" response-header field conveys the sender's estimate of the amount of time since the response was generated or successfully
+         validated at the origin server. Age values are calculated as specified in <a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>.
       </p>
       <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span>  <a href="#header.age" class="smpl">Age</a>   = "Age" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.age" class="smpl">Age-v</a>
@@ -992 +992 @@
       <div id="rfc.iref.h.3"></div>
       <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="header.cache-control" href="#header.cache-control">Cache-Control</a></h2>
-      <p id="rfc.section.3.2.p.1">The "Cache-Control" general-header field is used to specify directives that <em class="bcp14">MUST</em> be obeyed by all caches along the request/response chain. The directives specify behavior intended to prevent caches from
-         adversely interfering with the request or response. Cache directives are unidirectional in that the presence of a directive
-         in a request does not imply that the same directive is to be given in the response.
+      <p id="rfc.section.3.2.p.1">The "Cache-Control" general-header field is used to specify directives that <em class="bcp14">MUST</em> be obeyed by all caches along the request/response chain. Such cache directives are unidirectional in that the presence of
+         a directive in a request does not imply that the same directive is to be given in the response.
       </p>
       <div class="note"> 
@@ -1237 +1236 @@
       <div id="rfc.iref.h.6"></div>
       <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a id="header.vary" href="#header.vary">Vary</a></h2>
-      <p id="rfc.section.3.5.p.1">The "Vary" response-header field's value indicates the set of request-header fields that determines, while the response is
-         fresh, whether a cache is permitted to use the response to reply to a subsequent request without validation; see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.6</a>.
-      </p>
-      <p id="rfc.section.3.5.p.2">In uncacheable or stale responses, the Vary field value advises the user agent about the criteria that were used to select
+      <p id="rfc.section.3.5.p.1">The "Vary" response-header field conveys the set of request-header fields that were used to select the representation.</p>
+      <p id="rfc.section.3.5.p.2">Caches use this information, in part, to determine whether a stored response can be used to satisdy a given request; see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.6</a>. determines, while the response is fresh, whether a cache is permitted to use the response to reply to a subsequent request
+         without validation; see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.6</a>.
+      </p>
+      <p id="rfc.section.3.5.p.3">In uncacheable or stale responses, the Vary field value advises the user agent about the criteria that were used to select
          the representation.
       </p>
       <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.15"></span><span id="rfc.iref.g.16"></span>  <a href="#header.vary" class="smpl">Vary</a>   = "Vary" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.vary" class="smpl">Vary-v</a>
   <a href="#header.vary" class="smpl">Vary-v</a> = "*" / 1#<a href="#abnf.dependencies" class="smpl">field-name</a>
-</pre><p id="rfc.section.3.5.p.4">The set of header fields named by the Vary field value is known as the selecting request-headers.</p>
-      <p id="rfc.section.3.5.p.5">Servers <em class="bcp14">SHOULD</em> include a Vary header field with any cacheable response that is subject to server-driven negotiation. Doing so allows a cache
+</pre><p id="rfc.section.3.5.p.5">The set of header fields named by the Vary field value is known as the selecting request-headers.</p>
+      <p id="rfc.section.3.5.p.6">Servers <em class="bcp14">SHOULD</em> include a Vary header field with any cacheable response that is subject to server-driven negotiation. Doing so allows a cache
          to properly interpret future requests on that resource and informs the user agent about the presence of negotiation on that
          resource. A server <em class="bcp14">MAY</em> include a Vary header field with a non-cacheable response that is subject to server-driven negotiation, since this might provide
          the user agent with useful information about the dimensions over which the response varies at the time of the response.
       </p>
-      <p id="rfc.section.3.5.p.6">A Vary field value of "*" signals that unspecified parameters not limited to the request-headers (e.g., the network address
+      <p id="rfc.section.3.5.p.7">A Vary field value of "*" signals that unspecified parameters not limited to the request-headers (e.g., the network address
          of the client), play a role in the selection of the response representation; therefore, a cache cannot determine whether this
          response is appropriate. The "*" value <em class="bcp14">MUST NOT</em> be generated by a proxy server; it may only be generated by an origin server.
       </p>
-      <p id="rfc.section.3.5.p.7">The field-names given are not limited to the set of standard request-header fields defined by this specification. Field names
+      <p id="rfc.section.3.5.p.8">The field-names given are not limited to the set of standard request-header fields defined by this specification. Field names
          are case-insensitive.
       </p>