Re: [squid-users] AVG Updates not being cached with squid 2.6?

On Tue, 08 Dec 2009 23:21:54 +0800, Richard Chapman
<rchapman_at_aardvark.com.au> wrote:
> Amos Jeffries wrote:
>> Richard Chapman wrote:
>>> Amos Jeffries wrote:
>>>> Richard Chapman wrote:
>>>>> I have a more or less default configured squid 2.6 proxy on a
>>>>> centos 5.4 server.
>>>>> I have configured AVG 9 network edition (Virus scanner) to use the
>>>>> squid proxy (as opposed to the avg proxy) - and it appears to be
>>>>> doing so.
>>>>> However - checking the usage logs - it appears that different
>>>>> client machines download identical update (.bin) files within a few
>>>>> hours of each other - but do not appear to get a cache hit..
>>>>>
>>>>> Can anyone suggest why these update files are not being cached (or
>>>>> at least not getting cache hits) - and whether there is anything I
>>>>> can do to encourage them to be cached?
>>>>>
>>>>> I have checked the Squid FAQ and searched the archive - and found a
>>>>> similar request from 2005. The suggestion there was that the AVG
>>>>> server might be using the
>>>>>
>>>>> "Pragma: no-cache" HTTP header
>>>>
>>>> To be sure take the URL that should be a HIT and enter it at
>>>> redbot.org.
>>>> The whole problems should be easily visible there.
>>>>
>>>>>
>>>>> And that at that time there was no suggestion on how to override
>>>>> this. Can anyone confirm that this is the reason for the apparently
>>>>> unnecessary cache misses - and if so - is there anything new in
>>>>> squid to allow us to override?
>>>>>
>>>>
>>>> Squid which do not ignore "Pragma: no-cache" treat it the same as
>>>> "Cache-Control: no-cache"
>>>>
>>>> Amos
>>> Thanks Amos
>>> I tried redbot as you suggested - and this is a url which I think
>>> SHOULD have been a hit - though it is hard to be sure. The stats show
>>> that NONE of the avg updates come from cache - and I assume they
>>> should all have similar headers... Hopefully someone more
>>> knowledgeable than I can make more sense of this;
>>>
>>>
http://redbot.org/?uri=http://aa.avg.com/softw/90/update/u7iavi2551u2550qp.bin
>>>
>>>
>>>
>>>
>>> It looks to me that it should be cacheable - but the only suspicious
>>> thing is the statement I get when I hover over the "This response is
>>> stale". I think it says that it has a "Freshnes lifetime of 0" -
>>> which sounds like it will always be considered stale. I'm not sure
>>> why they would do this as each update has a unique file name - and
>>> could therefore be considered fresh indefinitely couldn't it?
>>>
>>> Can anyone confirm my interpretation - and/or suggest a way to treat
>>> the updates more rationally?
>>>
>>> Richard.
>>>
>>>
>>>
>>> A cache considers a HTTP response stale when its age (here, 0) is
>>> equal to or exceeds its freshness lifetime (in this case, 0)
>>>
>>> A A cache considers a HTTP response stale when its age (here, 0) is
>>> equal to or exceeds its freshness lifetime (in this case, 0).cache
>>> considers a HTTP response stale when its age (here, 0) is equal to or
>>> exceeds its freshness lifetime (in this case, 0).
>>
>> Hmm, something strange there.
>>
>> AFAIK the object looks like with the L-M header + the Date should have
>> both non-zero freshness (Date - LM) and an age (now - Date).
>>
>> Amos
>
> Thanks Amos
> Can you shed ANY light on what might be going on here? I presume you are

> seeing the same "odd" freshness and age numbers as I am.
> Can you enlighten me on what "LM" means or stands for?

Sorry; "Last-Modified:" header timestamp. It says how old the object is
from last create/modify.

> Are you suggesting that the AVG website is doing something odd to
> concoct the strange age and freshness numbers?

No, I think redbot is broken here, maybe Squid-2.6 as well. AFAIK it AVG
are right and it should be cached.

Anothee possibility is regex patterns. I notice the string "avi" in that
filename. Do you have some special regex in your config for handling video
DiVX files by extension?

> Where could an inconsistency arise to give zero for both these numbers -

> as seen by redbot?

unknown to me.

>
> I am very new to this stuff - and need help interpreting the data...:-)
> This all started from the observation that all AVG updates seem to be
> cache misses - even when the same update file is downloaded several
> times in a few hours.
>
>
> Richard.

Amos
Received on Wed Dec 09 2009 - 01:49:53 MST