On Thu, Aug 19, 2010 at 10:10 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote: > This category are tested so often on high-speed pathways they can only use > the data immediately available in memory and will not do remote lookups for > auth or external helper results. > > They will *sometimes* be able to use cached in-memory results from previous > lookups. So the the "slow" category ACL types are not prohibited in "fast" > category access controls. But they are not guaranteed to work 100% of the > time either. > > > I suspect your http_access rules are different when testing for the two > groups. In such a way that the "throttled" ACL never gets tested in > http_access (causing its result to be cached for delay_Access). > > > My favorite hack for pre-caching these types of lookup results for later use > is to test the ACL by itself early in the config with !all tacked on the end > of the line (which prevents the line as a whole matching and doing the > allow/deny). Thanks! And you'd be dead right. That's exactly what was happening. The test against another group was succeeding as it had already been used for Internet access by proxy_auth. I now have another problem, however, in that it appears you can't AND multiple ACLs to determine whether or not they can access a delay pool. Say for instance, I wanted to do: delay_access 1 allow throttled badfiles delay_access 1 deny all This would throttle only when members of the 'throttled' acl attempt to download files in the 'badfiles' acl. I can apply the pool to one ACL or the other, but not both. I also tried getting cheeky and stacking multiple conditions into the ACL definition. eg: acl throttled urlpath_regex -i "/etc/squid/badfiles.txt" acl throttled external ldap_group Internet-Throttled But squid doesn't like mixing multiple conditions to make a single acl. Is there a workaround for this? Thanks Richard