MINOR: Refine route-acl rules to prevent unintended prefix matches

[fabianonunes]

Since route-acl annotated rules take precedence over others, this PR updates its behavior to ensure they do not unintentionally overwrite other rules that share the same word prefix.

For example, a rule matching the path prefix /api should not inadvertently handle requests to /apiary.

To address this, the rule { path -m beg /api } has been replaced with a alternative that validates the URL's termination, ensuring it matches only /api$ or /api/.*:

# before this PR:
use_backend app_api_http if { var(txn.host) -m str api.demo } { path -m beg /api } { ... }

# after:
use_backend app_api_http if { var(txn.host) -m str api.demo } { path -m reg ^/api($|/) } { ... }

For better maintainability, this PR also refactors the AddCustomRoute function to eliminate redundancy introduced in commit c28d620. The updated code removes repetition without add extra spaces.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[fabianonunes]

I'd like to know if there's anything I can do to facilitate the merge of this PR.

I understand that using regex might have some performance impact (though I'm not sure about this). If that's a concern, we could implement two separate rules instead:

# matches all paths that begin with `/api/`
use_backend app_api_http if { var(txn.host) -m str api.demo } { path -m beg /api/ } { ... }
# matches all requests with the exact path `/api`
use_backend app_api_http if { var(txn.host) -m str api.demo } { path -m str /api } { ... }

This approach would achieve the same goal of preventing unintended matches (like /apiary) while potentially avoiding any regex performance overhead, if that's the case. Please let me know if there are any other concerns I can address to help move this PR forward.

Regarding the failed check HAProxy check commit message, I've already added the word acl to the dictionary and force-pushed, but the job hasn't been re-executed yet.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[fabianonunes]

Hi, @oktalz.

Could you please keep this pull request open until it can be reviewed? It was closed automatically. If there's anything I can do to help move it forward, let me know.

Thank you!

[oktalz]

@fabianonunes yes, we will take care of it soon

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ivanmatmati]

Hi @fabianonunes , we need to discuss if this is something we want to integrate because the documentation says:

Note that this annotation is not compatible with an Ingress having multiple paths that will match a request. Without this annotation, the precedence is given first to the longest matching path. But with the annotation, the first use_backend rule in the config that matches the request will be used.

Your PR could be an enhancement but we need to check if we want to go this direction. There's also a failing e2e test, can you check what happened ?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[oktalz]

@fabianonunes sry for the delay, merging it now