Changeset 2100 for draft-ietf-httpbis/latest

Timestamp:

08/01/13 00:27:15 (10 years ago)

Author:

mnot@…

Message:

Clarify rules for 304 updates, motivate last point; addresses #406

Location:

draft-ietf-httpbis/latest

Files:

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

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

@@ -452 +452 @@
   } 
   @bottom-center {
-       content: "Expires July 9, 2013"; 
+       content: "Expires July 12, 2013"; 
   } 
   @bottom-right {
@@ -492 +492 @@
       <link href="p5-range.html" rel="prev">
       <link href="p7-auth.html" rel="next">
-      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.589, 2012-11-30 14:23:31, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
+      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.589, 2012-11-30 14:23:31, XSLT vendor: SAXON 9.1.0.8 from Saxonica http://www.saxonica.com/">
       <link rel="schema.dct" href="http://purl.org/dc/terms/">
       <meta name="dct.creator" content="Fielding, R.">
@@ -498 +498 @@
       <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="2013-01-05">
+      <meta name="dct.issued" scheme="ISO8601" content="2013-01-08">
       <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 requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
@@ -524 +524 @@
             </tr>
             <tr>
-               <td class="left">Expires: July 9, 2013</td>
+               <td class="left">Expires: July 12, 2013</td>
                <td class="right">J. Reschke, Editor</td>
             </tr>
@@ -533 +533 @@
             <tr>
                <td class="left"></td>
-               <td class="right">January 5, 2013</td>
+               <td class="right">January 8, 2013</td>
             </tr>
          </tbody>
@@ -559 +559 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on July 9, 2013.</p>
+      <p>This Internet-Draft will expire on July 12, 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>
@@ -1064 +1064 @@
       <h3 id="rfc.section.4.2.1"><a href="#rfc.section.4.2.1">4.2.1</a>&nbsp;<a id="freshening.responses" href="#freshening.responses">Freshening Responses with 304 Not Modified</a></h3>
       <p id="rfc.section.4.2.1.p.1">When a cache receives a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response and already has one or more stored <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> 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 <a href="p4-conditional.html#status.304" class="smpl">304</a> response. 
-      </p>
+         and then update the stored response(s) with the new information provided in the <a href="p4-conditional.html#status.304" class="smpl">304</a> response.
+      </p>
+      <p id="rfc.section.4.2.1.p.2">The stored response to update is identified by using the first match (if any) of: </p>
       <ul>
          <li>If the new response contains a strong validator, then that strong validator identifies the selected representation. All of
@@ -1074 +1075 @@
             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.4.2.1.p.2">If a stored response is selected for update, the cache <em class="bcp14">MUST</em>: 
+         <li>If the new response does not include any form of validator (such as in the case where a client generates an If-Modified-Since
+            request from a source other than the Last-Modified response header field), and 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.4.2.1.p.3">If a stored response is selected for update, the cache <em class="bcp14">MUST</em>: 
       </p>
       <ul>

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

@@ -877 +877 @@
    are updated by this new response and then update the stored response(s)
    with the new information provided in the <x:ref>304</x:ref> response.
+</t>
+<t>
+   The stored response to update is identified by using the first match (if
+   any) of:
    <list style="symbols">
     <t>
@@ -891 +895 @@
     </t>
     <t>
-     If the new response does not include any form of validator, there is
+     If the new response does not include any form of validator (such as in
+     the case where a client generates an If-Modified-Since request from a
+     source other than the Last-Modified response header field), and there is
      only one stored response, and that stored response also lacks a
      validator, then that stored response is selected.