I'm a bit confused now. Examples from default config: acl localnet src 10.0.0.0/8 # RFC1918 possible internal network acl localnet src 172.16.0.0/12 # RFC1918 possible internal network acl localnet src 192.168.0.0/16 # RFC1918 possible internal network acl localnet src fc00::/7 # RFC 4193 local private network range acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines
acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl Safe_ports port 1025-65535 # unregistered ports All these ACL work as OR, right? Why is req_header different? On Thu, Dec 29, 2016 at 9:44 PM, Amos Jeffries <squ...@treenet.co.nz> wrote: > On 2016-12-29 21:01, Ivan Larionov wrote: > >> 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? >> > > Good find. You are the first to mention it. > > 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. > > 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). > > 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. > > Amos > > _______________________________________________ > squid-users mailing list > squid-users@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users > -- With best regards, Ivan Larionov.
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users