<div dir="ltr">I'm a bit confused now. Examples from default config:<div><br></div><div><div>acl localnet src <a href="http://10.0.0.0/8">10.0.0.0/8</a> # RFC1918 possible internal network</div><div>acl localnet src <a href="http://172.16.0.0/12">172.16.0.0/12</a> # RFC1918 possible internal network</div><div>acl localnet src <a href="http://192.168.0.0/16">192.168.0.0/16</a> # RFC1918 possible internal network</div><div>acl localnet src fc00::/7 # RFC 4193 local private network range</div><div>acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines</div><div><br></div><div>acl Safe_ports port 80 # http</div><div>acl Safe_ports port 21 # ftp</div><div>acl Safe_ports port 443 # https</div><div>acl Safe_ports port 70 # gopher</div><div>acl Safe_ports port 210 # wais</div><div>acl Safe_ports port 280 # http-mgmt</div><div>acl Safe_ports port 488 # gss-http</div><div>acl Safe_ports port 591 # filemaker</div><div>acl Safe_ports port 777 # multiling http</div><div>acl Safe_ports port 1025-65535 # unregistered ports</div></div><div><br></div><div>All these ACL work as OR, right?</div><div><br></div><div>Why is <span style="font-size:12.8px">req_header</span><span style="font-size:12.8px"> different?</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 29, 2016 at 9:44 PM, Amos Jeffries <span dir="ltr"><<a href="mailto:squid3@treenet.co.nz" target="_blank">squid3@treenet.co.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 2016-12-29 21:01, Ivan Larionov wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I see behavior change after update from squid 2.7 to 3.5:<br>
<br>
I have following ACLs which I later use for cache_peer_access:<br>
<br>
acl header req_header header_a -i true<br>
acl header req_header header_b -i true<br>
<br>
# name1 parent<br>
cache_peer 127.0.0.1 parent 18070 0 no-query no-digest name=name1<br>
cache_peer_access name1 deny header<br>
<br>
# name2 parent<br>
cache_peer 127.0.0.1 parent 18079 0 no-query no-digest name=name2<br>
cache_peer_access name2 allow header<br>
cache_peer_access name2 deny all<br>
<br>
With squid 2.7 it was working as expected (requests with header_a OR<br>
header_b were going to the second parent, all other requests to the<br>
first one).<br>
<br>
However with squid 3.5 the same config doesn't work as expected. ONLY<br>
requests with header_b are going to the second parent and debug logs<br>
show that squid only does verification of header_b.<br>
<br>
My current workaround is to use 2 different ACL names:<br>
<br>
acl header_a req_header header_a -i true<br>
acl header_b req_header header_b -i true<br>
<br>
# name1 parent<br>
cache_peer 127.0.0.1 parent 18070 0 no-query no-digest name=name1<br>
cache_peer_access name1 deny header_a<br>
cache_peer_access name1 deny header_b<br>
<br>
# name2 parent<br>
cache_peer 127.0.0.1 parent 18079 0 no-query no-digest name=name2<br>
cache_peer_access name2 allow header_a<br>
cache_peer_access name2 allow header_b<br>
cache_peer_access name2 deny all<br>
<br>
But I think it could be a bug. Multiple ACLs with the same name should<br>
work as OR, right? Do I understand it correctly? And it was working as<br>
expected in 2.7.<br>
<br>
Has anyone saw similar behavior? Should I report a bug?<br>
</blockquote>
<br></div></div>
Good find. You are the first to mention it.<br>
<br>
I have had a look back into the code history and don't see this as ever being an intended behaviour for Squid-2. Just a side effect of how the Squid-2 ACL lists happened to be stored internally.<br>
<br>
The intended design for ACLs is that basic/primitive tests check one piece of state data and get chained explicitly in the access lines for AND/OR conditions. That way it is clear what is being processed and matched (or not matched).<br>
<br>
So for now I am making Squid produce a config ERROR when this config situation is found. The 'anyof' or 'allof' ACL types in 3.4+ can be used to assemble a more complex test set checking different ACL primitives.<br>
<br>
Amos<br>
<br>
______________________________<wbr>_________________<br>
squid-users mailing list<br>
<a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.<wbr>org</a><br>
<a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">http://lists.squid-cache.org/l<wbr>istinfo/squid-users</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">With best regards, Ivan Larionov.</div>
</div>