Changeset 823 for draft-ietf-httpbis/latest/p6-cache.xml

Timestamp:

26/05/10 17:25:13 (12 years ago)

Author:

julian.reschke@…

Message:

Introduce term "effective request URI" and use it throughout; may require some more fine-tuning (see #196)

File:

• draft-ietf-httpbis/latest/p6-cache.xml (modified) (6 diffs)

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

@@ -18 +18 @@
   <!ENTITY basic-rules                 "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY uri                         "<xref target='Part1' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+  <!ENTITY effective-request-uri      "<xref target='Part1' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY messaging                   "<xref target='Part1' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY conditional                 "<xref target='Part4' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
@@ -478 +479 @@
   For a presented request, a cache &MUST-NOT; return a stored response, unless: 
   <list style="symbols">
-    <t>The presented Request-URI and that of the stored response match
-      (<cref anchor="TODO-Request-URI">Need to find a new term for this, as Part
-      1 doesn't define Request-URI anymore; the new term request-target does not
-      work for this. (see <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196" />)</cref>), and</t>
+    <t>The presented Effective Request URI (&effective-request-uri;) and that of the stored response match, and</t>
     <t>the request method associated with the stored response allows it to be 
       used for the presented request, and</t>
@@ -798 +796 @@
 </t>
 <t>
-  The following HTTP methods &MUST; cause a cache to invalidate the Request-URI as well
+  The following HTTP methods &MUST; cause a cache to invalidate the Effective Request URI (&effective-request-uri;) as well
   as the URI(s) in the Location and Content-Location headers (if present):
   <list style="symbols">
@@ -808 +806 @@
 <t>
   An invalidation based on a URI from a Location or Content-Location header &MUST-NOT;
-  be performed if the host part of that URI differs from the host part in the Request-URI.
+  be performed if the host part of that URI differs from the host part in the Effective Request URI (&effective-request-uri;).
   This helps prevent denial of service attacks.
 </t>
@@ -816 +814 @@
 <t>
   A cache that passes through requests for methods it does not understand &SHOULD;
-  invalidate the Request-URI.
+  invalidate the Effective Request URI (&effective-request-uri;).
 </t>
 <t>
   Here, "invalidate" means that the cache will either remove all stored responses related
-  to the Request-URI, or will mark these as "invalid" and in need of a mandatory validation
+  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.
 </t>
@@ -2450 +2448 @@
   </list>
 </t>
+<t>
+  Partly resolved issues:
+  <list style="symbols"> 
+    <t>
+      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196"/>:
+      "Term for the requested resource's URI"
+    </t>
+  </list>
+</t>
 </section>