Changeset 1314 for draft-ietf-httpbis/latest

Timestamp:

29/06/11 01:27:43 (10 years ago)

Author:

mnot@…

Message:

Cache invalidation only happens on non-error responses; addresses #235

Location:

draft-ietf-httpbis/latest

Files:

• p6-cache.html (modified) (7 diffs)
• p6-cache.xml (modified) (3 diffs)

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

@@ -362 +362 @@
   } 
   @bottom-center {
-       content: "Expires December 3, 2011"; 
+       content: "Expires December 31, 2011"; 
   } 
   @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-06-01">
+      <meta name="dct.issued" scheme="ISO8601" content="2011-06-29">
       <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. 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: December 3, 2011</td>
+               <td class="left">Expires: December 31, 2011</td>
                <td class="right">J. Mogul</td>
             </tr>
@@ -495 +495 @@
             <tr>
                <td class="left"></td>
-               <td class="right">June 1, 2011</td>
+               <td class="right">June 29, 2011</td>
             </tr>
          </tbody>
@@ -523 +523 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on December 3, 2011.</p>
+      <p>This Internet-Draft will expire on December 31, 2011.</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>
@@ -968 +968 @@
          to keep their contents up-to-date.
       </p>
-      <p id="rfc.section.2.5.p.2">A cache <em class="bcp14">MUST</em> invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) as well as the URI(s) in the Location and Content-Location header fields (if present) when requests with unsafe methods
-         are received.
+      <p id="rfc.section.2.5.p.2">A cache <em class="bcp14">MUST</em> invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) as well as the URI(s) in the Location and Content-Location header fields (if present) when a non-error response to a request
+         with an unsafe method is received.
       </p>
       <p id="rfc.section.2.5.p.3">However, a cache <em class="bcp14">MUST NOT</em> invalidate a URI from a Location or Content-Location header field if the host part of that URI differs from the host part
          in the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). This helps prevent denial of service attacks.
       </p>
-      <p id="rfc.section.2.5.p.4">A cache <em class="bcp14">SHOULD</em> invalidate the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) when passing through requests with methods whose safety is unknown.
-      </p>
-      <p id="rfc.section.2.5.p.5">Here, "invalidate" means that the cache will either remove all stored responses related to the effective request URI, or will
-         mark these as "invalid" and in need of a mandatory validation before they can be returned in response to a subsequent request.
+      <p id="rfc.section.2.5.p.4">A cache <em class="bcp14">SHOULD</em> invalidate the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) when it receives a non-error response to a request with a method whose safety is unknown.
+      </p>
+      <p id="rfc.section.2.5.p.5">Here, a "non-error response" is one with a 2xx or 3xx status code. "Invalidate" means that the cache will either remove all
+         stored responses related to the effective request URI, or will mark these as "invalid" and in need of a mandatory validation
+         before they can be returned in response to a subsequent request.
       </p>
       <p id="rfc.section.2.5.p.6">Note that this does not guarantee that all appropriate responses are invalidated. For example, the request that caused the
@@ -1971 +1972 @@
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/289">http://tools.ietf.org/wg/httpbis/trac/ticket/289</a>&gt;: "Proxies don't 'understand' methods"
          </li>
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/235">http://tools.ietf.org/wg/httpbis/trac/ticket/235</a>&gt;: "Cache Invalidation only happens upon successful responses"
+         </li>
       </ul>
       <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>

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

@@ -882 +882 @@
    caches can use them to keep their contents up-to-date.
 </t>
+
+Here, a non-error response is one with a 2xx or 3xx status code. 
+
 <t>
    A cache &MUST; invalidate the effective Request URI 
    (&effective-request-uri;) as well as the URI(s) in the Location
-   and Content-Location header fields (if present) when requests with
-   unsafe methods are received.
+   and Content-Location header fields (if present) when a non-error 
+   response to a request with an unsafe method is received.
 </t>
 <t>
@@ -896 +899 @@
 <t>
    A cache &SHOULD; invalidate the effective request URI 
-   (&effective-request-uri;) when passing through requests with methods
-   whose safety is unknown.
-</t>
-<t>
-   Here, "invalidate" means that the cache will either remove all stored
+   (&effective-request-uri;) when it receives a non-error response 
+   to a request with a method whose safety is unknown.
+</t>
+<t>
+   Here, a "non-error response" is one with a 2xx or 3xx status code.
+   "Invalidate" means that the cache will either remove all stored
    responses related to the effective request URI, or will mark these as
    "invalid" and in need of a mandatory validation before they can be returned
@@ -2723 +2727 @@
       "Proxies don't 'understand' methods"
     </t>
+    <t>
+            <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/235"/>:
+            "Cache Invalidation only happens upon successful responses"
+          </t>
   </list>
 </t>