Changeset 1419 for draft-ietf-httpbis/latest

Timestamp:

Aug 29, 2011, 6:05:39 PM (8 years ago)

Author:

mnot@…

Message:

Move 'freshening responses' under 'validation model'

Location:

draft-ietf-httpbis/latest

Files:

• p6-cache.html (modified) (11 diffs)
• p6-cache.xml (modified) (2 diffs)

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

@@ -362 +362 @@
   } 
   @bottom-center {
-       content: "Expires February 27, 2012"; 
+       content: "Expires March 2, 2012"; 
   } 
   @bottom-right {
@@ -408 +408 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2011-08-26">
+      <meta name="dct.issued" scheme="ISO8601" content="2011-08-30">
       <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. HTTP has been in use by the World Wide Web global information initiative since 1990. 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.">
@@ -434 +434 @@
             </tr>
             <tr>
-               <td class="left">Expires: February 27, 2012</td>
+               <td class="left">Expires: March 2, 2012</td>
                <td class="right">J. Mogul</td>
             </tr>
@@ -495 +495 @@
             <tr>
                <td class="left"></td>
-               <td class="right">August 26, 2011</td>
+               <td class="right">August 30, 2011</td>
             </tr>
          </tbody>
@@ -525 +525 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on February 27, 2012.</p>
+      <p>This Internet-Draft will expire on March 2, 2012.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -567 +567 @@
                   </ul>
                </li>
-               <li>2.4&nbsp;&nbsp;&nbsp;<a href="#validation.model">Validation Model</a></li>
+               <li>2.4&nbsp;&nbsp;&nbsp;<a href="#validation.model">Validation Model</a><ul>
+                     <li>2.4.1&nbsp;&nbsp;&nbsp;<a href="#freshening.responses">Freshening Responses</a></li>
+                  </ul>
+               </li>
                <li>2.5&nbsp;&nbsp;&nbsp;<a href="#invalidation.after.updates.or.deletions">Request Methods that Invalidate</a></li>
                <li>2.6&nbsp;&nbsp;&nbsp;<a href="#caching.authenticated.responses">Shared Caching of Authenticated Responses</a></li>
                <li>2.7&nbsp;&nbsp;&nbsp;<a href="#caching.negotiated.responses">Caching Negotiated Responses</a></li>
                <li>2.8&nbsp;&nbsp;&nbsp;<a href="#combining.responses">Combining Partial Content</a></li>
-               <li>2.9&nbsp;&nbsp;&nbsp;<a href="#freshening.responses">Freshening Responses</a></li>
             </ul>
          </li>
@@ -964 +966 @@
       <div id="rfc.figure.u.7"></div><pre class="text">  resident_time = now - response_time;
   current_age = corrected_initial_age + resident_time;
-</pre><p id="rfc.section.2.3.2.p.13">Additional rules for requirements on parsing and encoding of dates and other potential problems with date encodings include:</p>
+</pre><p id="rfc.section.2.3.2.p.13">Additionally, to avoid common problems in date parsing:</p>
       <p id="rfc.section.2.3.2.p.14"> </p>
       <ul>
@@ -1007 +1009 @@
          that stored response.
       </p>
-      <p id="rfc.section.2.4.p.4">A 304 (Not Modified) response status code indicates that the stored response can be updated and reused; see <a href="#freshening.responses" title="Freshening Responses">Section&nbsp;2.9</a>.
-      </p>
-      <p id="rfc.section.2.4.p.5">A full response (i.e., one with a response body) indicates that none of the stored responses nominated in the conditional
-         request is suitable. Instead, a cache <em class="bcp14">SHOULD</em> use the full response to satisfy the request and <em class="bcp14">MAY</em> replace the stored response(s).
-      </p>
-      <p id="rfc.section.2.4.p.6">If a cache receives a 5xx response while attempting to validate a response, it <em class="bcp14">MAY</em> either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, it <em class="bcp14">MAY</em> return a previously stored response (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;2.3.3</a>).
-      </p>
+      <p id="rfc.section.2.4.p.4">Cache handling of a response to a conditional request is dependent upon its status code:</p>
+      <p id="rfc.section.2.4.p.5"> </p>
+      <ul>
+         <li>A 304 (Not Modified) response status code indicates that the stored response can be updated and reused; see <a href="#freshening.responses" title="Freshening Responses">Section&nbsp;2.4.1</a>.
+         </li>
+         <li>A full response (i.e., one with a response body) indicates that none of the stored responses nominated in the conditional
+            request is suitable. Instead, a cache <em class="bcp14">SHOULD</em> use the full response to satisfy the request and <em class="bcp14">MAY</em> replace the stored response(s).
+         </li>
+         <li>However, if a cache receives a 5xx response while attempting to validate a response, it <em class="bcp14">MAY</em> either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, it <em class="bcp14">MAY</em> return a previously stored response (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;2.3.3</a>).
+         </li>
+      </ul>
+      <h3 id="rfc.section.2.4.1"><a href="#rfc.section.2.4.1">2.4.1</a>&nbsp;<a id="freshening.responses" href="#freshening.responses">Freshening Responses</a></h3>
+      <p id="rfc.section.2.4.1.p.1">When a cache receives a 304 (Not Modified) response and already has one or more stored 200 (OK) responses for the same cache
+         key, the cache needs to identify which of the stored responses are updated by this new response and then update the stored
+         response(s) with the new information provided in the 304 response. 
+      </p>
+      <ul>
+         <li>If the new response contains a strong validator, then that strong validator identifies the selected representation. All of
+            the stored responses with the same strong validator are selected. If none of the stored responses contain the same strong
+            validator, then this new response corresponds to a new selected representation and <em class="bcp14">MUST NOT</em> update the existing stored responses.
+         </li>
+         <li>If the new response contains a weak validator and that validator corresponds to one of the cache's stored responses, then
+            the most recent of those matching stored responses is selected.
+         </li>
+         <li>If the new response does not include any form of validator, there is only one stored response, and that stored response also
+            lacks a validator, then that stored response is selected.
+         </li>
+      </ul>
+      <p id="rfc.section.2.4.1.p.2">If a stored response is selected for update, the cache <em class="bcp14">MUST</em>: 
+      </p>
+      <ul>
+         <li>delete any Warning header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section&nbsp;3.6</a>);
+         </li>
+         <li>retain any Warning header fields in the stored response with warn-code 2xx; and,</li>
+         <li>use other header fields provided in the 304 response to replace all instances of the corresponding header fields in the stored
+            response.
+         </li>
+      </ul>
       <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a>&nbsp;<a id="invalidation.after.updates.or.deletions" href="#invalidation.after.updates.or.deletions">Request Methods that Invalidate</a></h2>
       <p id="rfc.section.2.5.p.1">Because unsafe request methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 6.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) such as PUT, POST or DELETE have the potential for changing state on the origin server, intervening caches can use them
@@ -1076 +1109 @@
       </p>
       <ul>
-         <li>delete any Warning header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section&nbsp;3.6</a>);
+         <li>delete any Warning header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.3" title="Warning">Section&nbsp;3.6</a>);
          </li>
          <li>retain any Warning header fields in the stored response with warn-code 2xx; and,</li>
          <li>use other header fields provided in the new response, aside from Content-Range, to replace all instances of the corresponding
             header fields in the stored response.
-         </li>
-      </ul>
-      <h2 id="rfc.section.2.9"><a href="#rfc.section.2.9">2.9</a>&nbsp;<a id="freshening.responses" href="#freshening.responses">Freshening Responses</a></h2>
-      <p id="rfc.section.2.9.p.1">When a cache receives a 304 (Not Modified) response and already has one or more stored 200 (OK) responses for the same cache
-         key, the cache needs to identify which of the stored responses are updated by this new response and then update the stored
-         response(s) with the new information provided in the 304 response. 
-      </p>
-      <ul>
-         <li>If the new response contains a strong validator, then that strong validator identifies the selected representation. All of
-            the stored responses with the same strong validator are selected. If none of the stored responses contain the same strong
-            validator, then this new response corresponds to a new selected representation and <em class="bcp14">MUST NOT</em> update the existing stored responses.
-         </li>
-         <li>If the new response contains a weak validator and that validator corresponds to one of the cache's stored responses, then
-            the most recent of those matching stored responses is selected.
-         </li>
-         <li>If the new response does not include any form of validator, there is only one stored response, and that stored response also
-            lacks a validator, then that stored response is selected.
-         </li>
-      </ul>
-      <p id="rfc.section.2.9.p.2">If a stored response is selected for update, the cache <em class="bcp14">MUST</em>: 
-      </p>
-      <ul>
-         <li>delete any Warning header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.3" title="Warning">Section&nbsp;3.6</a>);
-         </li>
-         <li>retain any Warning header fields in the stored response with warn-code 2xx; and,</li>
-         <li>use other header fields provided in the 304 response to replace all instances of the corresponding header fields in the stored
-            response.
          </li>
       </ul>
@@ -2129 +2135 @@
                         <li>Pragma&nbsp;&nbsp;<a href="#rfc.xref.header.pragma.1">2.2</a>, <a href="#rfc.xref.header.pragma.2">3.2</a>, <a href="#rfc.iref.h.5"><b>3.4</b></a>, <a href="#rfc.xref.header.pragma.3">5.2</a></li>
                         <li>Vary&nbsp;&nbsp;<a href="#rfc.xref.header.vary.1">2.7</a>, <a href="#rfc.iref.h.6"><b>3.5</b></a>, <a href="#rfc.xref.header.vary.2">5.2</a></li>
-                        <li>Warning&nbsp;&nbsp;<a href="#rfc.xref.header.warning.1">2.3.3</a>, <a href="#rfc.xref.header.warning.2">2.8</a>, <a href="#rfc.xref.header.warning.3">2.9</a>, <a href="#rfc.iref.h.7"><b>3.6</b></a>, <a href="#rfc.xref.header.warning.4">5.2</a>, <a href="#rfc.xref.header.warning.5">A</a></li>
+                        <li>Warning&nbsp;&nbsp;<a href="#rfc.xref.header.warning.1">2.3.3</a>, <a href="#rfc.xref.header.warning.2">2.4.1</a>, <a href="#rfc.xref.header.warning.3">2.8</a>, <a href="#rfc.iref.h.7"><b>3.6</b></a>, <a href="#rfc.xref.header.warning.4">5.2</a>, <a href="#rfc.xref.header.warning.5">A</a></li>
                      </ul>
                   </li>
@@ -2280 +2286 @@
             </li>
             <li><a id="rfc.index.W" href="#rfc.index.W"><b>W</b></a><ul>
-                  <li>Warning header field&nbsp;&nbsp;<a href="#rfc.xref.header.warning.1">2.3.3</a>, <a href="#rfc.xref.header.warning.2">2.8</a>, <a href="#rfc.xref.header.warning.3">2.9</a>, <a href="#rfc.iref.w.1"><b>3.6</b></a>, <a href="#rfc.xref.header.warning.4">5.2</a>, <a href="#rfc.xref.header.warning.5">A</a></li>
+                  <li>Warning header field&nbsp;&nbsp;<a href="#rfc.xref.header.warning.1">2.3.3</a>, <a href="#rfc.xref.header.warning.2">2.4.1</a>, <a href="#rfc.xref.header.warning.3">2.8</a>, <a href="#rfc.iref.w.1"><b>3.6</b></a>, <a href="#rfc.xref.header.warning.4">5.2</a>, <a href="#rfc.xref.header.warning.5">A</a></li>
                </ul>
             </li>

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

@@ -960 +960 @@
    satisfied by that stored response.
 </t>
-<t>
-   A 304 (Not Modified) response status code indicates that the stored
-   response can be updated and reused; see <xref target="freshening.responses"/>.
-</t>
-<t>
-   A full response (i.e., one with a response body) indicates that none of the
-   stored responses nominated in the conditional request is suitable. Instead,
-   a cache &SHOULD; use the full response to satisfy the request and &MAY; 
-   replace the stored response(s).
-</t>
-<t>
-   If a cache receives a 5xx response while attempting to validate a response,
-   it &MAY; either forward this response to the requesting client, or act as
-   if the server failed to respond. In the latter case, it &MAY; return a
-   previously stored response (see <xref target="serving.stale.responses" />).
-</t>
+
+<t>Cache handling of a response to a conditional request is dependent upon its status code:</t>
+
+<t>
+   <list style="symbols">
+      <t>
+         A 304 (Not Modified) response status code indicates that the stored
+         response can be updated and reused; see <xref
+         target="freshening.responses"/>.
+      </t>
+      <t>
+         A full response (i.e., one with a response body) indicates that none
+         of the stored responses nominated in the conditional request is
+         suitable. Instead, a cache &SHOULD; use the full response to satisfy
+         the request and &MAY; replace the stored response(s).
+      </t>
+      <t>
+         However, if a cache receives a 5xx response while attempting to
+         validate a response, it &MAY; either forward this response to the
+         requesting client, or act as if the server failed to respond. In the
+         latter case, it &MAY; return a previously stored response (see <xref
+         target="serving.stale.responses" />).
+      </t>
+   </list>
+</t>
+
+<section anchor="freshening.responses" title="Freshening Responses">
+<t>
+   When a cache receives a 304 (Not Modified) response and already has one
+   or more stored 200 (OK) responses for the same cache key, the cache needs
+   to identify which of the stored responses are updated by this new response
+   and then update the stored response(s) with the new information provided in
+   the 304 response.
+   <list style="symbols">
+    <t>
+     If the new response contains a strong validator, then that strong
+     validator identifies the selected representation.  All of the stored
+     responses with the same strong validator are selected.
+     If none of the stored responses contain the same strong validator, then
+     this new response corresponds to a new selected representation and
+     &MUST-NOT; update the existing stored responses.
+    </t>
+    <t>
+     If the new response contains a weak validator and that validator
+     corresponds to one of the cache's stored responses, then the most
+     recent of those matching stored responses is selected.
+    </t>
+    <t>
+     If the new response does not include any form of validator, there is
+     only one stored response, and that stored response also lacks a
+     validator, then that stored response is selected.
+    </t>
+   </list>
+</t>
+<t>
+   If a stored response is selected for update, the cache &MUST;:
+   <list style="symbols">
+      <t>delete any Warning header fields in the stored response with
+         warn-code 1xx (see <xref target="header.warning" />);</t>
+      <t>retain any Warning header fields in the stored response with
+         warn-code 2xx; and,</t>
+      <t>use other header fields provided in the 304 response to replace
+         all instances of the corresponding header fields in the stored
+         response.</t>
+   </list>
+</t>
+</section>
+
 </section>
 
@@ -1122 +1174 @@
 </section>
 
-<section anchor="freshening.responses" title="Freshening Responses">
-<t>
-   When a cache receives a 304 (Not Modified) response and already has one
-   or more stored 200 (OK) responses for the same cache key, the cache needs
-   to identify which of the stored responses are updated by this new response
-   and then update the stored response(s) with the new information provided in
-   the 304 response.
-   <list style="symbols">
-    <t>
-     If the new response contains a strong validator, then that strong
-     validator identifies the selected representation.  All of the stored
-     responses with the same strong validator are selected.
-     If none of the stored responses contain the same strong validator, then
-     this new response corresponds to a new selected representation and
-     &MUST-NOT; update the existing stored responses.
-    </t>
-    <t>
-     If the new response contains a weak validator and that validator
-     corresponds to one of the cache's stored responses, then the most
-     recent of those matching stored responses is selected.
-    </t>
-    <t>
-     If the new response does not include any form of validator, there is
-     only one stored response, and that stored response also lacks a
-     validator, then that stored response is selected.
-    </t>
-   </list>
-</t>
-<t>
-   If a stored response is selected for update, the cache &MUST;:
-   <list style="symbols">
-      <t>delete any Warning header fields in the stored response with
-         warn-code 1xx (see <xref target="header.warning" />);</t>
-      <t>retain any Warning header fields in the stored response with
-         warn-code 2xx; and,</t>
-      <t>use other header fields provided in the 304 response to replace
-         all instances of the corresponding header fields in the stored
-         response.</t>
-   </list>
-</t>
-</section>
 
 </section>