Hi dev@trafficserver.apache.org,
We're processing through ACL filter action names for 10.x. For context, for
9.x and before, these are how actions behave for ip_allow.yaml rules and
remap.config ACL filters:
* ip_allow.yaml: These rules currently support allow and deny actions.
allow specifies an allow list of methods for requests, with all other
requests of different methods being denied. deny species a deny list of
methods, with all other requests of different methods being allowed. For
instance, an allow action ip_allow.yaml rule for GET and HEAD methods will
allow GET and HEAD requests, but deny all other methods, such as POST,
PUSH, etc.
* remap.config: Remap ACLs support allow and deny actions as well, but
these actions add to the allow list or add to the deny list for lower level
ACL filters or ip_allow.yaml rules. For instance, a deny ACL rule for POST
will add the denial of POST requests while allowing all other request
method filtering to be handled by other applicable remap filters or
ip_allow.yaml rules.
For 10.x, we plan to rename the latter ACL behavior to add_allow and
add_deny to clarify their behavior and to disambiguate them from the
ip_allow.yaml rule actions that previously had the same name. There is a
compatibility configuration, which will be on by default, which makes it so
that the allow and deny actions will still function as they did in 9.x.
Thus, 9.x remap.config ACLs will, by default, behave the same in 10.x.
10.x adds functionality to ACL filters such that they will support actions
that do behave like ip_allow.yaml allow and deny rules. That is, a user can
specify an ACL filter that will have an allow list of, say, GET and HEAD,
such that only GET and HEAD requests are allowed while all other methods
are denied, with no other filter actions or ip_allow.yaml rules being
inspected. In this way, the ACL filter will behave like an allow
ip_allow.yaml rule for GET and HEAD.
So the question for vote is: for this new 10.x behavior, how should we name
the ACL actions that will behave like ip_allow.yaml allow and deny actions?
The options are:
* *Keep the allow and deny action names for these filters*. These actions
will behave identically to the ip_allow.yaml actions: that is, they will
specify allow or deny lists, with requests of methods outside of those
lists being denied or allowed, respectively. (Again, to make this explicit
twice, by default ATS 10 will behave in compatibility mode in which the
allow and deny actions will act like add_allow and add_deny, just as they
did in 9.x. The question here is for non-compatibility mode for 10.x and
for the default 11.x behavior) The advantage of keeping allow/deny ACL
actions the same name as the ip_allow.yaml rule actions is that they will
in fact behave the same and those "allow" and "deny" actions are pretty
intuitive for ip_allow.yaml. That is, they allow or deny a list of methods.
The disadvantage is that someone not reading the release notes in 11.x,
say, after we remove the compatibility mode, will suddenly have their allow
and deny rules behaving differently and this will surprise them. And, since
we are re-using those names, ATS will not be able to warn the user of the
misuse of the old action because it won't be able to tell the difference
between an unintentional upgrade from 9.x allow/deny from an intentional
use of the new allow/deny semantic.
* The second option is to *rename these new actions* and not keep the old
"allow" and "deny" action names at all. For consistency, since these
actions will behave the same as the ip_allow.yaml actions that are
currently allow and deny, we should rename those as well. The rename can be
open to discussion, and doesn't have to hold up this vote. The vote is
whether to keep the same name, or to rename. But, just to give some ideas
of what this can look like, they can be renamed to "set_allow" and
"set_deny", or "allow_only" and "deny_only", or "allow_these" and
"deny_these". The advantage of the rename is that we will be able to mark
the old "allow" and "deny" actions as forbidden and warn the user that they
need to consciously choose either add_allow/add_deny or the new action
names we decide upon using. The disadvantage is that the "allow" and "deny"
actions are pretty clear and simple in their meanings, especially in
ip_allow.yaml, and we would be giving that up via the rename. Arguably, if
there weren't a compatibility issue, we would choose allow/add_allow and
deny/add_deny. If that's the case, an interlocutor could reason that giving
people a full release to transition is enough time to reuse original names
capturing the semantic which otherwise makes sense.
I hope that I am presenting the tradeoffs of the two options fairly, but
naturally feel free to add comments along with your vote.
Concisely, can you please vote on one of the following naming options for
these new ACL filter action behaviors which will function like allow/deny
ip_allow.yaml rule actions?
1. Keep the allow/deny action names.
2. Rename the allow/deny action names.
Thank you!
Brian
--
"Come to Me, all who are weary and heavy-laden, and I will
give you rest. Take My yoke upon you and learn from Me, for
I am gentle and humble in heart, and you will find rest for
your souls. For My yoke is easy and My burden is light."
~ Matthew 11:28-30
