Re: Cache revalidations

This is what is said in RFC 2616 on updating headers:

9.4 HEAD

   The response to a HEAD request MAY be cacheable in the sense that the
   information contained in the response MAY be used to update a
   previously cached entity from that resource. If the new field values
   indicate that the cached entity differs from the current entity (as
   would be indicated by a change in Content-Length, Content-MD5, ETag
   or Last-Modified), then the cache MUST treat the cache entry as
   stale.

[Squid caches the HEAD reply separately. I don't think we expunge stale
entries]

10.3.5 304 Not Modified

   If a cache uses a received 304 response to update a cache entry, the
   cache MUST update the entry to reflect any new field values given in
   the response.

[squid only updates the freshness of the object, we do not update the
response]

We do obviously have quite a bit to do here..

Regards
Henrik

Andres Kroonmaa wrote:

> Do we need to talk about all http headers, or only those that are
> currently covered with storeentry?
> a) seems ok for current state.
> b) is easy for FS like coss. for others it might be bad overhead.
> c) if we talk only of storeentry prepended to object, then we can
> consider overwriting just those bits after we have serviced object.
> Then we'd open file for r/w instead of just r. If we talk of full
> headers, then probably full object rewrite is the way.
>
> I'd definitely try to avoid rewriting full object anywhere but on coss.
> So I'd vote for 'c'.
>
> ------------------------------------
> Andres Kroonmaa <andre@online.ee>
> CTO, Microlink Online
> Tel: 6501 731, Fax: 6501 725
> Pärnu mnt. 158, Tallinn,
> 11317 Estonia
Received on Sat Oct 06 2001 - 02:41:01 MDT