On 25.09.2012 10:06, Alex Rousskov wrote:
Hello,
I would like to add support for explicit OR ACLs:
# ACL name will match if and only if any of its acl* ACLs match.
# The first matching acl (left-to-right) stops evaluation.
acl name or acl1 acl2 ...
As you know, existing Squid ACL rules are meant to be functionally
complete: they can express any combination of logical conditions
expressed by individual ACLs. However, specifying the right
combination
may require a very long and confusing configuration file.
I recently came across a real-world case where 20 reasonable
http_access
access rules had to be converted into more than 100 rules just to add
a
single "or the user does not need authentication" condition into the
"middle" of an existing rule set. The solution was so "big" and
required
such a rewrite of the existing rules that the admin thought that it
would be impossible to support his needs using Squid ACLs!
If OR ACLs are supported, no drastic increase in http_access rules
would
be required to solve the same problem.
Explicit OR (and AND) ACLs also allow an admin to group related ACLs
of
different types together and name them. This can be used to simplify
and
self-document configurations.
IIRC the subject of explicit OR ACL support has came up recently on
one
of the squid-dev threads, and there were positive remarks about
adding them.
Any objections to this new feature?
Only to agree with Robert that exposing this functionality adds too
much difficulty to explain.
IMO it would be better if this 'or' type was hidden and not usable
directly in the config.
Instead make it a magic ACL node/type created when we discover two (or
more) ACL types being assigned to the same *name*. The config dumper for
it can dump out the well-known acl sub-type lines for each sub-type list
and nothing for the parent aggregator.
For example:
acl alpha dstdomain .example.com
acl beta src localhost
acl foo or alpha beta
http_access allow foo
would instead be configured as:
acl foo dstdomain .example.com
acl foo src localhost
http_access allow foo
This way we have zero extra complexity to explain, except to say the
ACL may now support multiple types and emphasise the existing
documentation that 'acl' lines are OR sets, any one value may match.
Amos
