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

Timestamp:

Jul 29, 2010, 11:12:22 PM (9 years ago)

Author:

fielding@…

Message:

regenerate html, but needs appendix updates

File:

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

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

@@ -762 +762 @@
       </p>
       <ul>
-         <li>The presented 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.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and that of the stored response match, and
+         <li>The presented 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.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and that of the stored response match, and
          </li>
          <li>the request method associated with the stored response allows it to be used for the presented request, and</li>
@@ -946 +946 @@
          <li>POST</li>
       </ul>
-      <p id="rfc.section.2.5.p.3">An invalidation based on a URI from a Location or Content-Location header <em class="bcp14">MUST NOT</em> be performed 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 that passes through requests for methods it does not understand <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>).
-      </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
+      <p id="rfc.section.2.5.p.3">An invalidation based on a URI from a Location or Content-Location header <em class="bcp14">MUST NOT</em> be performed 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 that passes through requests for methods it does not understand <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>).
+      </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>
@@ -1012 +1012 @@
       <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>
       <p id="rfc.section.3.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.</p>
-      <p id="rfc.section.3.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who
-         receives the message.
-      </p>
       <div id="rfc.iref.a.2"></div>
       <div id="rfc.iref.h.2"></div>
@@ -1257 +1254 @@
       <div id="rfc.iref.h.4"></div>
       <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="header.expires" href="#header.expires">Expires</a></h2>
-      <p id="rfc.section.3.3.p.1">The "Expires" entity-header field gives the date/time after which the response is considered stale. See <a href="#expiration.model" title="Freshness Model">Section&nbsp;2.3</a> for further discussion of the freshness model.
+      <p id="rfc.section.3.3.p.1">The "Expires" header field gives the date/time after which the response is considered stale. See <a href="#expiration.model" title="Freshness Model">Section&nbsp;2.3</a> for further discussion of the freshness model.
       </p>
       <p id="rfc.section.3.3.p.2">The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after
@@ -1899 +1896 @@
       <p id="rfc.section.C.12.p.1">Closed issues: </p>
       <ul>
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/109">http://tools.ietf.org/wg/httpbis/trac/ticket/109</a>&gt;: "Clarify entity / representation / variant terminology"
+         </li>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/220">http://tools.ietf.org/wg/httpbis/trac/ticket/220</a>&gt;: "consider removing the 'changes from 2068' sections"
          </li>