No this has been always in V5, we now just added the hint. plz let me try to explain we are forced to do this.
We do the content filtering prior squid stores the content in its cache.
Assume you now have two different profiles, one for 'Sales' and one for the 'Development' or one for 'Kids' and one for 'Adults'.
Now if you are surfing the 'Adult' Profile, all your Content gets stored in the cache. If now your kids access the same pages, squid would deliver them out of the cache without validating it against the content filter.
In order to prevent this, we automatically disable caching of request as soon as you enable the content filter.
I know that this is not very satisfying, but as squid is not capable of adding addtitional information to its cached objects, something like 'profile_name', we can not make sure that the content squid woudl deliver to the client would match his content filter profile.
There are plans to improve this behavior in the future.
While looking a the Squid access log under V5.008 with SurfProtection activated, I noticed that hardly any cache hits occurred.
(Another reason why I would like to have the RRDTool graphs for the HTTP proxy back, as in V4 - tried to produce them myself last night by enabling SNMP port 3401 in squid.conf-default, but failed to get ASL V5 answer any snmp-get requests so far).
After seeing the new notice about the cache being disabled due to filtering being active, and after reading your explanation, I am however surprised to observe still cache hits and refresh hits, etc. flying past in the real-time log! Could it be that your implementation still uses pages that were cached before any content filter was activated? Actually my setup ran for about one week with caching only enabled, before I dared to enable URL filtering as well, after updating to 5.007.
Of course, I am looking forward to a more satisfactory solution, which you hint is under development. Because I used to explain to users and to my management that file caching makes up time that is lost with URL filtering, besides lowering bandwidth requirements, and hiding some of the high latency of our satellite links.
Now I realize that this does not hold true anymore with V5. Yet another reason to stick with V4 for the time being with our ASL installations deserving satellite links, besides waiting for a more stable implementation of Anti-Virus checking on the HTTP proxy - which is our main motivation to move to V5.
Keep up with the good work, and please post when you found a solution to improve this implementation aspect.
it just occurred to me that I only use one single (default) profile for the content filter. In this particular case re-enabling the cache should not pose any problems?
Is there any work-around to re-enable the cache from a root shell in v5.009 while we wait for the generic solution?
it just occurred to me that I only use one single (default) profile for the content filter. In this particular case re-enabling the cache should not pose any problems?
Is there any work-around to re-enable the cache from a root shell in v5.009 while we wait for the generic solution?
