RE: [squid-users] Strange misses of cacheable objects

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_at_treenet.co.nz]
Sent: Monday, April 14, 2014 12:19
To: squid-users_at_squid-cache.org
Subject: Re: [squid-users] 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
Received on Mon Apr 21 2014 - 00:29:02 MDT