[squid-users] acls with the same name, last wins

[Ivan Larionov]

I see behavior change after update from squid 2.7 to 3.5:

I have following ACLs which I later use for cache_peer_access:

acl header req_header header_a -i true
acl header req_header header_b -i true

# name1 parent
cache_peer 127.0.0.1 parent 18070 0 no-query no-digest name=name1
cache_peer_access name1 deny header

# name2 parent
cache_peer 127.0.0.1 parent 18079 0 no-query no-digest name=name2
cache_peer_access name2 allow header
cache_peer_access name2 deny all

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).

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.

My current workaround is to use 2 different ACL names:

acl header_a req_header header_a -i true
acl header_b req_header header_b -i true

# name1 parent
cache_peer 127.0.0.1 parent 18070 0 no-query no-digest name=name1
cache_peer_access name1 deny header_a
cache_peer_access name1 deny header_b

# name2 parent
cache_peer 127.0.0.1 parent 18079 0 no-query no-digest name=name2
cache_peer_access name2 allow header_a
cache_peer_access name2 allow header_b
cache_peer_access name2 deny all

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.

Has anyone saw similar behavior? Should I report a bug?

-- 
With best regards, Ivan Larionov.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20161229/d41fdff1/attachment.html>