#227: HEAD and Caches

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

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?


<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/227>


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

Received on Tuesday, 7 February 2012 04:10:07 UTC