I’d vote for 2. Rename them and we can make the allow/deny actions a syntax error so they get caught early.
Something I wasn’t clear on, Can you confirm that this is planned for ATS 11 or 10.x - not the upcoming release of 10? Matt On 2024/07/22 17:44:27 Brian Neradt wrote: > 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 >
