Changeset 691

Timestamp:

Sep 11, 2009, 2:58:13 AM (10 years ago)

Author:

julian.reschke@…

Message:

remove requirement to consider Content-Location in successful responses in order to determine the appropriate response to use (see #167)

Location:

draft-ietf-httpbis/latest

Files:

• p6-cache.html (modified) (14 diffs)
• p6-cache.xml (modified) (3 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-01">
+      <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-11">
       <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 5, 2010</td>
+            <td class="header left">Expires: March 15, 2010</td>
             <td class="header right">HP</td>
          </tr>
@@ -487 +487 @@
          <tr>
             <td class="header left"></td>
-            <td class="header right">September 1, 2009</td>
+            <td class="header right">September 11, 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 5, 2010.</p>
+      <p>This Internet-Draft will expire in March 15, 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>
@@ -902 +902 @@
       <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.7">If a cache receives a successful response whose Content-Location field matches that of an existing stored response for the
-         same Request-URI, whose entity-tag differs from that of the existing stored response, and whose Date is more recent than that
-         of the existing response, the existing response <em class="bcp14">SHOULD NOT</em> be returned in response to future requests and <em class="bcp14">SHOULD</em> be deleted from the cache. <span class="comment" id="rfc.comment.6">[<a href="#rfc.comment.6" class="smpl">rfc.comment.6</a>: DISCUSS: Not sure if this is necessary.]</span> 
-      </p>
       <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 methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) have the potential for changing state on the origin server, intervening caches can use them to keep their contents up-to-date.
@@ -919 +915 @@
          attacks.
       </p>
-      <p id="rfc.section.2.5.p.4"> <span class="comment" id="rfc.comment.7">[<a href="#rfc.comment.7" class="smpl">rfc.comment.7</a>: TODO: "host part" needs to be specified better.]</span> 
+      <p id="rfc.section.2.5.p.4"> <span class="comment" id="rfc.comment.6">[<a href="#rfc.comment.6" class="smpl">rfc.comment.6</a>: TODO: "host part" needs to be specified better.]</span> 
       </p>
       <p id="rfc.section.2.5.p.5">A cache that passes through requests for methods it does not understand <em class="bcp14">SHOULD</em> invalidate the Request-URI.
@@ -929 +925 @@
          change at the origin server might not have gone through the cache where a response is stored.
       </p>
-      <p id="rfc.section.2.5.p.8"> <span class="comment" id="rfc.comment.8">[<a href="#rfc.comment.8" class="smpl">rfc.comment.8</a>: TODO: specify that only successful (2xx, 3xx?) responses invalidate.]</span> 
+      <p id="rfc.section.2.5.p.8"> <span class="comment" id="rfc.comment.7">[<a href="#rfc.comment.7" class="smpl">rfc.comment.7</a>: TODO: specify that only successful (2xx, 3xx?) responses invalidate.]</span> 
       </p>
       <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a>&nbsp;<a id="caching.negotiated.responses" href="#caching.negotiated.responses">Caching Negotiated Responses</a></h2>
@@ -936 +932 @@
       </p>
       <p id="rfc.section.2.6.p.2">The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first
-         request can be transformed to the selecting request-headers in the second request by adding or removing linear white space <span class="comment" id="rfc.comment.9">[<a href="#rfc.comment.9" class="smpl">rfc.comment.9</a>: [ref]]</span> at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field
+         request can be transformed to the selecting request-headers in the second request by adding or removing linear white space <span class="comment" id="rfc.comment.8">[<a href="#rfc.comment.8" class="smpl">rfc.comment.8</a>: [ref]]</span> at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field
          name following the rules about header fields in <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
       </p>
@@ -951 +947 @@
          be used to satisfy the request.
       </p>
-      <p id="rfc.section.2.7.p.2">If the new response contains an ETag, it identifies the stored response to use. <span class="comment" id="rfc.comment.10">[<a href="#rfc.comment.10" class="smpl">rfc.comment.10</a>: may need language about Content-Location here]</span><span class="comment" id="rfc.comment.11">[<a href="#rfc.comment.11" class="smpl">rfc.comment.11</a>: cover case where INM with multiple etags was sent]</span> 
+      <p id="rfc.section.2.7.p.2">If the new response contains an ETag, it identifies the stored response to use. <span class="comment" id="rfc.comment.9">[<a href="#rfc.comment.9" class="smpl">rfc.comment.9</a>: may need language about Content-Location here]</span><span class="comment" id="rfc.comment.10">[<a href="#rfc.comment.10" class="smpl">rfc.comment.10</a>: cover case where INM with multiple etags was sent]</span> 
       </p>
       <p id="rfc.section.2.7.p.3">If the status code is 206 (partial content), both the stored and new responses <em class="bcp14">MUST</em> have validators, and those validators <em class="bcp14">MUST</em> match using the strong comparison function (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). Otherwise, the responses <em class="bcp14">MUST NOT</em> be combined.
@@ -966 +962 @@
       <p id="rfc.section.2.7.p.5">If a header field-name in the new response matches more than one header in the stored response, all such stored headers <em class="bcp14">MUST</em> be replaced.
       </p>
-      <p id="rfc.section.2.7.p.6">The updated response can [[<span class="comment" id="rfc.comment.12">[<a href="#rfc.comment.12" class="smpl">rfc.comment.12</a>: requirement?]</span>]] be used to replace the stored response in cache. In the case of a 206 response, the combined entity-body <em class="bcp14">MAY</em> be stored.
-      </p>
-      <p id="rfc.section.2.7.p.7"> <span class="comment" id="rfc.comment.13">[<a href="#rfc.comment.13" class="smpl">rfc.comment.13</a>: ISSUE: discuss how to handle HEAD updates]</span> 
+      <p id="rfc.section.2.7.p.6">The updated response can [[<span class="comment" id="rfc.comment.11">[<a href="#rfc.comment.11" class="smpl">rfc.comment.11</a>: requirement?]</span>]] be used to replace the stored response in cache. In the case of a 206 response, the combined entity-body <em class="bcp14">MAY</em> be stored.
+      </p>
+      <p id="rfc.section.2.7.p.7"> <span class="comment" id="rfc.comment.12">[<a href="#rfc.comment.12" class="smpl">rfc.comment.12</a>: ISSUE: discuss how to handle HEAD updates]</span> 
       </p>
       <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
@@ -1054 +1050 @@
             time. If max-stale is assigned a value, then the client is willing to accept a response that has exceeded its expiration time
             by no more than the specified number of seconds. If no value is assigned to max-stale, then the client is willing to accept
-            a stale response of any age. <span class="comment" id="rfc.comment.14">[<a href="#rfc.comment.14" class="smpl">rfc.comment.14</a>: of any staleness? --mnot]</span></dd>
+            a stale response of any age. <span class="comment" id="rfc.comment.13">[<a href="#rfc.comment.13" class="smpl">rfc.comment.13</a>: of any staleness? --mnot]</span></dd>
       </dl>
       <p id="rfc.section.3.2.1.p.6"> <span id="rfc.iref.c.8"></span>  <span id="rfc.iref.m.3"></span> min-fresh 
@@ -1537 +1533 @@
       <p id="rfc.section.A.1.p.2">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow
          for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are
-         computed. (see also <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> and <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) <span class="comment" id="rfc.comment.15">[<a href="#rfc.comment.15" class="smpl">rfc.comment.15</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span> 
-      </p>
-      <p id="rfc.section.A.1.p.3">Proxies should be able to add Content-Length when appropriate. <span class="comment" id="rfc.comment.16">[<a href="#rfc.comment.16" class="smpl">rfc.comment.16</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span> 
+         computed. (see also <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> and <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) <span class="comment" id="rfc.comment.14">[<a href="#rfc.comment.14" class="smpl">rfc.comment.14</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span> 
+      </p>
+      <p id="rfc.section.A.1.p.3">Proxies should be able to add Content-Length when appropriate. <span class="comment" id="rfc.comment.15">[<a href="#rfc.comment.15" class="smpl">rfc.comment.15</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span> 
       </p>
       <p id="rfc.section.A.1.p.4">Range request responses would become very verbose if all meta-data were always returned; by allowing the server to only send
@@ -1549 +1545 @@
       </p>
       <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2>
-      <p id="rfc.section.A.2.p.1">Clarify denial of service attack avoidance requirement. (<a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section&nbsp;2.5</a>)
-      </p>
-      <p id="rfc.section.A.2.p.2">Do not mention RFC 2047 encoding and multiple languages in Warning headers anymore, as these aspects never were implemented.
+      <p id="rfc.section.A.2.p.1">Remove requirement to consider Content-Location in successful responses in order to determine the appropriate response to
+         use. (<a href="#validation.model" title="Validation Model">Section&nbsp;2.4</a>)
+      </p>
+      <p id="rfc.section.A.2.p.2">Clarify denial of service attack avoidance requirement. (<a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section&nbsp;2.5</a>)
+      </p>
+      <p id="rfc.section.A.2.p.3">Do not mention RFC 2047 encoding and multiple languages in Warning headers anymore, as these aspects never were implemented.
          (<a href="#header.warning" id="rfc.xref.header.warning.5" title="Warning">Section&nbsp;3.6</a>)
       </p>
@@ -1721 +1720 @@
       <p id="rfc.section.C.9.p.1">Closed issues: </p>
       <ul>
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/167">http://tools.ietf.org/wg/httpbis/trac/ticket/167</a>&gt;: "Content-Location on 304 responses"
+         </li>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/187">http://tools.ietf.org/wg/httpbis/trac/ticket/187</a>&gt;: "RFC2047 and warn-text"
          </li>

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

@@ -756 +756 @@
   target="serving.stale.responses" />).
 </t>
-<t>
-  If a cache receives a successful response whose Content-Location field  
-  matches that of an existing stored response for the same Request-URI,  
-  whose entity-tag differs from that of the existing stored response,  
-  and whose Date is more recent than that of the existing response, the  
-  existing response &SHOULD-NOT; be returned in response to future  
-  requests and &SHOULD; be deleted from the cache. <cref>DISCUSS: Not  
-  sure if this is necessary.</cref>
-</t>
 </section>
 
@@ -2070 +2061 @@
 <section anchor="changes.from.rfc.2616" title="Changes from RFC 2616">
 <t>
+  Remove requirement to consider Content-Location in successful responses
+  in order to determine the appropriate response to use.
+  (<xref target="validation.model" />)
+</t>
+<t>
   Clarify denial of service attack avoidance requirement.
   (<xref target="invalidation.after.updates.or.deletions" />)
@@ -2309 +2305 @@
   <list style="symbols"> 
     <t>
+      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/167"/>:
+      "Content-Location on 304 responses"
+    </t>
+    <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/187"/>:
       "RFC2047 and warn-text"