Re: #227: HEAD and Caches

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

Received on Tuesday, 7 February 2012 06:07:58 UTC