Re: #227: HEAD and Caches

2012/3/2 Mark Nottingham <mnot@mnot.net>

>
> 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>
>

Copy/paste bug in the following paragraph?


> +      <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>
>
>
Good clarifications.

In a related note: Is it allowed for a cache to rewrite a HEAD request to a
GET if there previously is no entity stored for that request?
Maybe there should be some text on that, or is that an implementation
detail?

--
Erlend Hamnaberg