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