Re: #227: HEAD and Caches

Looks good to me, if correcting the copy-paste 304 reference.

fre 2012-03-02 klockan 17:19 +1100 skrev Mark Nottingham:
> 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 12:05:02 UTC