On 15/02/2014 10:35 a.m., Niki Gorchilov wrote: > Hi all, > > I keep exploring the darkest corners of the Squid universe thus > meeting unexpected creatures. :-) > > Today's discovery is hier_code ACL. > > I stumbled upon it while looking for a way to prevent SMP workers from > swapping duplicate objects they got from the shared memory cache. > > On second thought, hier_code could also help me prevent swapping > objects fetched from cache peers, making my peername ACL redundant. > > Oh, great! 2-in-1. Let's do it: > > ===[cut]=== > # swap only objects fetched directly from source > # objects fetched from cache peers or > # shared memory shall not be cached > acl direct hier_code HIER_DIRECT > acl direct hier_code CLOSEST_DIRECT > acl direct hier_code SOURCE_FASTEST > acl direct hier_code PINNED > acl direct hier_code ORIGINAL_DST > cache allow direct > cache deny all > ===[cut]=== > > Unfortunately, the above config prevented ANY objects from being > cached, like the hier_code wasn't available at the time the swap > decision is taken. > > Am I doing it wrong? Is it possible to use hier_code acl against cache > deny/allow? 1) Lets start with "swap" and "swapping". What exactly do you mean by those words? Your usage does not seem to mean the same as storing data on disk, and exchanging objects in a two-way transaction does not match HTTP. 2) "cache" access control determines whether object are stored by the current Squid in any of the cache areas. It is checked right after receiving the request, so things like how it will be fetched are completely unkown. 3) hier_code is available from the point a successful server connection has been made. Up until that point it is "NONE". It should work in the tcp_outgoing_* access controls which are done on a per-destination basis on each hierarchy path. But I am not sure of that. Amos
