Amos, Antony, Thanks for your replies. Actually, the refresh_pattern rules that apply to all the cases indicate to overwrite the Expires header field and force the object to the cache (they all have override-expire ignore-private ignore-no-cache reload-into-ims options), so Date == Expires should not be a problem or refresh_pattern options are implemented incorrectly. With respect to Vary and ETag fields, there are lots of other objects that have similar values and they cache perfectly. Also, please note that the requests are made for the same object from the same browser on the same machine with some seconds to minutes of difference in between, so the headers are absolutely identical in each request and the objects, if still fresh, should be cached. And some hours later I started to get hits for some of these object and some hours later misses again (and I mean hits and misses on various requests in a row, say 5 requests for the same object with an interval of 10 seconds all return hits, some hours later the same return all misses, so it's not that the objects expired). Try requesting these objects multiple times at different moments of a day and you probably will see the same behavior. It looks like there is a problem with the current implementation; I don't see any solid reason for these objects not to cache. Regards, Anatoli P.S. My email was blocked (blacklisted) by my hosting provider for 4 working days after sending a single mail to this list. They said it was marked as spam more than once. Is it something to expect? Is it possible to post to this list without sending an email? Any web interface? -----Original Message----- From: Amos Jeffries [mailto:squid3@xxxxxxxxxxxxx] Sent: Monday, April 14, 2014 12:19 To: squid-users@xxxxxxxxxxxxxxx Subject: Re: Strange misses of cacheable objects On 15/04/2014 1:07 a.m., Anatoli wrote: > Dear all, > > I have some strange misses of cacheable objects. Here is an example (there > are a lot of these objects): > > http://www.googletagmanager.com/gtm.js?id=GTM-J5TM > As Michael said this one is expired immediately on arrival. Note: in HTTP/1.1 expired responses ARE cacheable without any special actions. It is also private data for the individual client. Squid is now enforcing revalidation of private responses which make their way into the cache. That ensures the new requestor is a valid recipient of any cached response. > Some other links with very similar request/response headers and squid log > entries are > http://www.googleadservices.com/pagead/conversion_async.js Same for this one in regards to immediate expiry. However the ETag header contains invalid values so HTTP/1.1 revalidation does not work. > http://cdn.clicktale.net/www07/ptc/3a4e2875-764c-4dd7-8d30-db51f1744e3e.js > http://cdn.clicktale.net/www/tc/WRe10.js These URL are emitting a mix of different Vary: header contents. Which make caching highly volatile and likely to produce incorrect responses to clients. The ETag header used for unique object identification on the second one is also containing invalid values (this time duplicates) in some responses. Both of these server errors will cause erratic behaviour in the caching of the objects as they undermine the reliability of the response. > > http://armdl.adobe.com/pub/adobe/reader/win/9.x/9.5.0/en_US/AdbeRdr950_en_US > .exe has the same behavior and was already reported by Marko Cupać @ May 15, > 2013; 7:17am in "adobe updates constantly re-downloading" mail. Nobody > offered any solution. Since Marko's original post I have seen simialr behaviour on a different clients network when the user account logged into the machine did not have permission to install software yet Adobe updater was running anyway and failing at the beginning install stage. Amos
