<div dir="ltr">I see behavior change after update from squid 2.7 to 3.5:<div><br></div><div>I have following ACLs which I later use for cache_peer_access:<br><div><br></div><div><div>acl header req_header header_a -i true</div><div>acl header req_header header_b -i true</div></div><div><br></div><div><div># name1 parent</div><div>cache_peer 127.0.0.1 parent 18070 0 no-query no-digest name=name1</div><div>cache_peer_access name1 deny header</div><div><br></div><div># name2 parent</div><div>cache_peer 127.0.0.1 parent 18079 0 no-query no-digest name=name2</div><div>cache_peer_access name2 allow header</div><div>cache_peer_access name2 deny all</div></div><div><br></div><div>With squid 2.7 it was working as expected (requests with header_a OR header_b were going to the second parent, all other requests to the first one).</div><div><br></div><div>However with squid 3.5 the same config doesn't work as expected. ONLY requests with header_b are going to the second parent and debug logs show that squid only does verification of header_b.</div><div><br></div><div>My current workaround is to use 2 different ACL names:</div><div><br></div><div><div>acl header_a req_header header_a -i true</div><div>acl header_b req_header header_b -i true</div><div><br></div><div><div># name1 parent</div><div>cache_peer 127.0.0.1 parent 18070 0 no-query no-digest name=name1</div><div>cache_peer_access name1 deny header_a</div><div>cache_peer_access name1 deny header_b</div><div><br></div><div># name2 parent</div><div>cache_peer 127.0.0.1 parent 18079 0 no-query no-digest name=name2</div><div>cache_peer_access name2 allow header_a</div><div>cache_peer_access name2 allow header_b</div><div>cache_peer_access name2 deny all</div></div><div><br></div><div>But I think it could be a bug. Multiple ACLs with the same name should work as OR, right? Do I understand it correctly? And it was working as expected in 2.7.</div><div><br></div><div>Has anyone saw similar behavior? Should I report a bug?</div><div><br></div>-- <br><div class="gmail_signature">With best regards, Ivan Larionov.</div>
</div></div></div>