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.
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
