<div dir="ltr"><div>Hi all,</div><div><br></div><div>I've got a squid server running which allows direct proxy and also can intercept traffic:</div><div><br></div><div>http_port <a href="http://10.0.0.1:3128">10.0.0.1:3128</a></div><div>http_port <a href="http://10.0.0.1:3129">10.0.0.1:3129</a> intercept</div><div><br></div><div>---</div><div><br></div><div>There is a URL rewriter which allows the incoming requests (this is just an example, I don't really allow all):</div><div><br></div><div>url_rewrite_access allow all</div><div>url_rewrite_program /usr/bin/myrewriter</div><div><br></div><div>---</div><div><br></div><div>This rewriter will rewrite some URLs to a host on the same network, with the intention that the request should not be cached by squid, eg</div><div><a href="http://example.net/somefile.bin">http://example.net/somefile.bin</a> -> <a href="http://10.0.0.2/example.net/somefile.bin">http://10.0.0.2/example.net/somefile.bin</a></div><div>So a cache_deny directive is used for this:</div><div><br></div><div>acl local_store dst 10.0.0.2</div><div>cache deny local_store</div><div><br></div><div>---</div><div><br></div><div>Now when requesting this URL using a defined proxy the ACL matches and the request is not cached. If using intercept the ACL does not match and it does get cached (which caused some storage duplication on the network)</div><div>The debug info shows the following:</div><div><br></div><div>Proxy:</div><div>curl -x "<a href="http://10.0.0.1:3128">10.0.0.1:3128</a>" "<a href="http://example.net/somefile.bin">http://example.net/somefile.bin</a>" > /dev/null</div><div>Ip.cc(95) aclIpAddrNetworkCompare: aclIpAddrNetworkCompare: compare: <a href="http://10.0.0.2/[ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff]">10.0.0.2/[ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff]</a> (10.0.0.2)  vs 10.0.0.2-[::]/[ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff]</div><div><br></div><div>Intercept:</div><div>curl "<a href="http://example.net/somefile.bin">http://example.net/somefile.bin</a>" > /dev/null # Intercepted on the NAT tables</div><div>Ip.cc(95) aclIpAddrNetworkCompare: aclIpAddrNetworkCompare: compare: <a href="http://93.184.216.34:80/[ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff]">93.184.216.34:80/[ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff]</a> (<a href="http://93.184.216.34:80">93.184.216.34:80</a>)  vs 10.0.0.2-[::]/[ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff]</div><div><br></div><div>This seems to show that the ACL is processed at a different stage for the two different modes. Now I'm wondering if this is intentional and I shouldn't be using the 'dst' ACL here, or should it be more consistant and give the same result regardless?</div><div><br></div><div>I have a solution to use the 'url_regex' ACL instead which seems consistant between the two modes, but it may slightly affect performance.</div><div><br></div><div>I couldn't find a huge amount of info on what order the ACLs are processed, so if anybody could let me know what the expected behaviour should be that would be much appreciated.</div><div><br></div><div>Thanks,</div><div>Craig</div></div>