Re: #227: HEAD and Caches

On 16/02/2012, at 6:25 PM, Henrik Nordström wrote:

> mån 2012-02-13 klockan 15:45 +1100 skrev Mark Nottingham:
>> New:   
>> 
>> The response to a HEAD request is cacheable; it MAY be used to satisfy
>> subsequent HEAD requests. 
> 
> You just lost the property of HEAD updating GET responses. This is a
> very intentional property.
> 
> HEAD response == GET response minus body. As such it has the same cache
> metadata update properties as 304 responses or merge of 204 responses.


Proposal:


Index: p2-semantics.xml
===================================================================
--- p2-semantics.xml	(revision 1553)
+++ p2-semantics.xml	(working copy)
@@ -85,6 +85,7 @@
   <!ENTITY p6-heuristic               "<xref target='Part6' x:rel='#heuristic.freshness' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY p6-explicit                "<xref target='Part6' x:rel='#calculating.freshness.lifetime' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY p6-invalid                 "<xref target='Part6' x:rel='#invalidation.after.updates.or.deletions' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+  <!ENTITY p6-head                 "<xref target='Part6' x:rel='#head.effects' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
 ]>
 <?rfc toc="yes" ?>
 <?rfc symrefs="yes" ?>
@@ -1035,12 +1036,8 @@
 </t>
 <t>
    The response to a HEAD request is cacheable and &MAY; be used to satisfy
-   a subsequent HEAD request; see &caching;. It also &MAY; be used to update a previously cached
-   representation from that resource; if the new field values
-   indicate that the cached representation differs from the current representation (as
-   would be indicated by a change in Content-Length, ETag
-   or Last-Modified), then the cache &MUST; treat the cache entry as
-   stale.
+   a subsequent HEAD request. It also has potential side effects on
+   previously stored responses to GET; see &p6-head;.
 </t>
 <t>
    Bodies on HEAD requests have no defined semantics. Note that sending a body



Index: p6-cache.xml
===================================================================
--- p6-cache.xml	(revision 1553)
+++ p6-cache.xml	(working copy)
@@ -1013,7 +1013,7 @@
    </list>
 </t>
 
-<section anchor="freshening.responses" title="Freshening Responses">
+<section anchor="freshening.responses" title="Freshening Responses with 304 Not Modified">
 <t>
    When a cache receives a 304 (Not Modified) response and already has one
    or more stored 200 (OK) responses for the same cache key, the cache needs
@@ -1055,8 +1055,40 @@
 </t>
 </section>
 
+<section anchor="head.effects" title="Updating Caches with HEAD Responses">
+<t>
+   A response to the HEAD method is identical to what an equivalent request
+   made with a GET would have been, except it lacks a body. This property
+   of HEAD responses is used to both invalidate and update cached GET
+   responses.
+</t>
+<t>
+   If one or more stored GET responses can be selected (as per <xref
+   target="caching.negotiated.responses"/>) for a HEAD request, and the
+   Content-Length, ETag or Last-Modified value of a HEAD response differs from
+   that in a selected GET response, the cache &MUST; consider that selected
+   response to be stale.
+</t>
+<t>
+   If the Content-Length, ETag and Last-Modified values of a HEAD response
+   (when present) are the same as that in a selected GET response (as per
+   <xref target="caching.negotiated.responses"/>), the cache SHOULD update the
+   remaining headers in the stored response using the following rules:
+   <list style="symbols">
+      <t>delete any Warning header fields in the stored response with
+         warn-code 1xx (see <xref target="header.warning" />);</t>
+      <t>retain any Warning header fields in the stored response with
+         warn-code 2xx; and,</t>
+      <t>use other header fields provided in the 304 response to replace
+         all instances of the corresponding header fields in the stored
+         response.</t>
+   </list>
+</t>
+
 </section>
 
+</section>
+
 <section anchor="invalidation.after.updates.or.deletions" 
    title="Request Methods that Invalidate">
 <t>



--
Mark Nottingham   http://www.mnot.net/

Received on Friday, 2 March 2012 06:20:22 UTC