Changeset 484

Timestamp:

Mar 3, 2009, 9:05:11 PM (11 years ago)

Author:

mnot@…

Message:

rework caching negotiated responses.

File:

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

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

@@ -695 +695 @@
 
       <section anchor="caching.negotiated.responses" title="Caching Negotiated Responses">
-        <t>Use of server-driven content negotiation (&server-driven-negotiation;), as indicated
-          by the presence of a Vary header field (<xref target="header.vary" />) in a response, alters
+        <t>Use of server-driven content negotiation (&server-driven-negotiation;) alters
           the conditions and procedure by which a cache can use the response for subsequent
           requests.</t>
-        <t>When the cache receives a subsequent request which may be satisfied by a stored responses
-          that include a Vary header field, it &MUST-NOT; use it to satisfy the request unless
+        <t>When the cache receives a request which may be satisfied by a stored response
+          that includes a Vary header field, it &MUST-NOT; use the stored response to satisfy the request unless
           all of the selecting request-headers present in the new request match the corresponding
           stored request-headers from the original request.</t>
@@ -708 +707 @@
           <cref>[ref]</cref> 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 message headers in &message-headers;.</t>
-        <t>A Vary header field-value of "*" always fails to match, and subsequent requests on that
+          about message headers in &message-headers;. <cref>DISCUSS: header-specific canonicalisation</cref></t>
+        <t>A Vary header field-value of "*" always fails to match, and subsequent requests to that
           resource can only be properly interpreted by the origin server.</t>
-        <t>If the selecting request-headers for the stored response do not match the selecting
-          request header fields of the new request, then the cache &MUST-NOT; use the stored
-          response to satisfy the request unless it first relays the new request to the origin
-          server in a conditional request and the server responds with 304 (Not Modified), including
-          an entity tag or Content-Location that indicates the entity to be used.</t>
-        <t>If one or more applicable stored response has an entity tag, the forwarded request
-          &SHOULD; be conditional and include all of these entity tags in an If-None-Match
-          header field. This conveys to the server the set of entities currently stored by the
-          cache, so that if any one of these entities matches the requested entity, the server can
-          use the ETag header field in its 304 (Not Modified) response to tell the cache which
-          stored response is appropriate. If the entity-tag of the new response matches that of an
-          existing stored resopnse, the new response &SHOULD; be used to update its header
-          fields, and the result &MUST; be returned to the client.</t>
-        <t>If any of the existing stored responses contains only partial content for the associated
-          entity, its entity-tag &SHOULD-NOT; be included in the If-None-Match header field
-          unless the request is for a range that would be fully satisfied by that stored response.</t>
+        <t>If they fail to match, the cache &MAY; forward the presented request to the origin
+          server in a conditional request, which &SHOULD; include all ETags stored with 
+          potentially suitable responses in an If-None-Match request header. If the server responds with 304 (Not Modified) and
+          includes an entity tag or Content-Location that indicates the entity to be used, that
+          cached response &MUST; be used to satisfy the presented request, and &SHOULD;
+          be used to update the corresponding stored response; see <xref target="combining.headers"/>.</t>
+        <t>If any of the stored responses contains only partial content, its entity-tag &SHOULD-NOT; 
+          be included in the If-None-Match header field unless the request is for a range that would 
+          be fully satisfied by that stored response.</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.</t>
-        <t>
-          <cref>TODO: this still needs work.</cref>
-        </t>
+          requests and &SHOULD; be deleted from the cache.<cref>DISCUSS: Not sure if this is necessary.</cref></t>
       </section>