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?
Are you suggesting that the AVG website is doing something odd to
concoct the strange age and freshness numbers?
Where could an inconsistency arise to give zero for both these numbers -
as seen by redbot?
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.
