Re: #227: HEAD and Caches

Proposal --

Old: 

  The response to a HEAD request is cacheable and MAY be used to satisfy a
  subsequent HEAD request; see [Part6]. 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.
   
New:   

The response to a HEAD request is cacheable; it MAY be used to satisfy
subsequent HEAD requests. 

If the Content-Length, ETag or Last-Modified value of a HEAD response differs
from that in the selected GET response (as per [ref to p6 2.7]), the cache
MUST consider that selected response to be stale.



On 07/02/2012, at 5:04 PM, Amos Jeffries wrote:

> On 7/02/2012 5:03 p.m., Mark Nottingham wrote:
>> I've been bothered by this text (p2 6.4 HEAD) for a while:
>> 
>>>    The response to a HEAD request is cacheable and MAY be used to
>>>    satisfy a subsequent HEAD request; see [Part6].  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 few problems:
>> 
>> 1. Since it specifies required cache behaviour, it really should be in p6
>> 2. The second MAY seems to conflict with the MUST
>> 3. Caches can store multiple representations for a resource, so there is no "current representation."
> 
> My reading is that there is an erroneous ";" in the middle of the second sentence and "current" is the origins viewpoint of current.
> 
> 
>> 
>> Part of the problem here really is that it's not "updating" any response, but it is potentially invalidating an old one.
>> 
>> To resolve this, we could construct a requirement that refers to p6 2.7 ("Caching Negotiated Responses") to identify the correct response to compare to and (potentially) invalidate.
>> 
>> However, I wonder if a) this is widely implemented, and b) the complexity is worth it.
>> 
>> I.e., we could alternatively just remove everything after the first sentence (i.e., treat the second MAY as primary, and therefore make the whole thing redundant).
>> 
>> Thoughts?
> 
> Its useful that a HEAD 200 be treated identically to how the equivalent GET 200 response would have regarding invalidation and content negotiation details. The absence of a body seems not particularly relevant to the act of or reasons for invalidation. The presence of a body is just a performance edge GET conditionals have over HEAD.
> 
> The paragraph does seem like a convoluted way of saying that though.
> 
> IMHO changing that second paragraph to "SHOULD invalidate" and referencing the negotiation section for the what/how/when bits is the right thing to do, even if not implemented very widely right now. The origins HEAD result having changed is a very clear sign that the cached representation is not really useful now anyway.
> 
> AYJ
> 
>> 
>> 
>> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/227>
>> 
>> 
>> --
>> Mark Nottingham   http://www.mnot.net/
>> 
>> 
>> 
>> 
> 
> 

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

Received on Monday, 13 February 2012 04:46:09 UTC