2012/9/8 Amos Jeffries <squid3_at_treenet.co.nz>:
> On 7/09/2012 10:53 a.m., E.S. Rosenberg wrote:
>>
>> Hi all,
>> We have the following proxy structure at the moment:
>>
>>
>> Internet --- Squid cache1 --- Squid cache2 --- users
>> |
>> ICAP Anti Virus server
>>
>> The documentation of the AV server states clearly that they don't
>> recommend having a caching proxy behind it because then a virus may be
>> cached and served for a while.
>>
>> If this is indeed the case then I would like squid cache2 to send of
>> only the cache-hits for a rescan because the misses anyhow already
>> passed through SQ1 and were scanned, is this possible?
>
>
> Yes by re-ordering cache2 closer to the Internet than cache1.
Cache2 is the "user facing" cache that does most authentication and is
different per campus/area whereas cache1 is a general cache that all
instances of cache2 are supposed to talk to, so reordering isn't
really an option.
Connecting the ICAP server to the instances of Cache2 may be an
option, but may require us creating multiple ICAP servers since some
of the Cache2's sit in different locations and them shipping the file
back and forth over WAN would kind of kill the whole gain of a local
cache.
>
> The ordering you show above HITS on cache2 will never even reach cache1.
That I understood, that's why I was trying to see if there was a way
to ship off just the HITS to ICAP.
>
>
>>
>> Also it seems to me that this anyhow may not be 100% true, because
>> would the AV server not warn when squid tries to establish of the file
>> has gone stale before serving it?
>
>
> No. The revalidation process usually only involves an IMS request and short
> 304 response. No object gets transferred during that process. I think they
> are meaning that the cached objects need re-scanning after AV signatures get
> updated, the revalidate would not trigger any re-scan.
Right so only if the site itself got blacklisted in the meantime and
therefor some form of 40x (403?) get returned via ICAP to Cache1 would
the virus be blocked.
Thanks,
Eli
>
> Amos
Received on Sun Sep 09 2012 - 13:13:41 MDT
This archive was generated by hypermail 2.2.0 : Sun Sep 09 2012 - 12:00:02 MDT