On 2016-12-31 10:58, Ivan Larionov wrote:
I'm a bit confused now. Examples from default config: acl localnet src 10.0.0.0/8 [2] # RFC1918 possible internal network acl localnet src 172.16.0.0/12 [3] # RFC1918 possible internal network acl localnet src 192.168.0.0/16 [4] # 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?
Yes. They put the port or IP values into a bucket/set of values that are matched in OR style.
You can list the port/IP ACls values all on one line if you want and it works identically to listing them on separate lines.
Why is req_header different?
With the req_header (and rep_header) in Squid-3 only the regex portion provides that "line and list being identical" property, the header name changing requires a new line.
Squid-2 appears to have implemented the ACL as a set of header names with the regex being a secondary lookup. So if any of the headers existed the set of regex were then tested and that was the overall result.
It can probably be made to work the Squid-2 way (if its really needed make a feature enhancement bug), but Squid-3 has the allof and anyof ACLs now to make an explicit logic tree where this type of OR requirement is clearly visible in the config file. These new ACL tests walk their tree of AND/OR ACL conditions and the overall match/non-match is whatever the leaf ACL test says. Thats a lot more flexible.
Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
