Chris Wedgwood wrote:
> 1.2beta24 does not appear to cache HEAD objects. Using a clean cache,
> I was unable to make HEAD requests come from cache until I actually
> issue a GET, after that time, HEAD request are satisfied from cache.
Well.. beta24 was very confused by HEAD replies, and had some other
mismatches between persistent and non-persistent server connections.. I
have now submitted a patch to squid-bugs that tries to tidy up this
small mess.
Squid has always tried to cache HEAD replies with various success. It is
needed since HEAD is used by some common autoated tools (the most well
known one is wget).
Your idea that HEAD replies should be seen as 0 bytes objects is not
that stupid as HEAD is defined to give exactly the same headers as a GET
would (but without the body), but it has some important drawbacks:
mainly what to do if we get HEAD requests for expired objects?
Today Squid caches HEAD and GET replies with separate keys to allow HEAD
replies to be cached without interfering with GET replies. The drawback
from this is that some additional code is needed to keep them in sync
(i.e. avoiding that one is newer than the other). This is mainly done by
prefering headers from GET replies over those from HEAD replies unless
the GET reply has expired/needs revalidation (which can cause a new
object to be transferred, defeating the purpose of HEAD).
/Henrik
Received on Tue Jul 29 2003 - 13:15:53 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:11:54 MST