Martin4R commented on PR #2897:
URL:
https://github.com/apache/apisix-ingress-controller/pull/2897#issuecomment-6125008069
Hi @AlinsRan,
I just tried the solution you suggested in point 2, but it looks as if it
would not work.
I created 2 apisix-routes in the api-driven config via endpoint
/apisix/admin/configs.
The first route would be my PathPrefix route, so I gave it uris:
["/argocd/api/v1/applications/*"]
The second route would be like my RegexExpression route for let's say
"^/argocd/.*/syncwindows", which by your suggestion would get uris:
["/argocd/*"].
Then I used a request which matches both rules with uri
"/argocd/api/v1/applications/apisix/syncwindows" and tried to give the
RegexExpression route a higher priority value than the PathPrefix route. Sadly
the priority is still ignored in that case, because the uri generated for the
PathPrefix route ("/argocd/api/v1/applications/*") is of course a lot more
specific than the uri generated from the RegexExpression route ("/argocd/*").
Therefore the current implementation in this MR seems to me to be the only
way to make all the different path-expressions consistent so that the priority
field can be used to order them.
You are correct so, about the current MR implementation would be a breaking
change for users who have a regex catch-all route "/.*". My thought was, that
RegexExpression would be used only for very specific paths and therefore should
take precedence, because it is easier to write a PathPrefix Gateway API rule
for most of the simple, less specific cases (including a PathPrefix of "/" as
catch-all route. PathPrefix rules also have the advantage of being ordered by
their length already. The use case of a regex catch-all route would be a
counter-example, because there, a RegexExpression is used for a very unspecific
path. If a user has such a rule, wouldn't he already need to make sure in some
way that it does not take precedence over other RegexExpression rules, because
they have no predefined order? In case this MR implements this as a breaking
change and documents that, it would be easy for the user to adapt to that by
assigning a low priority to their catch-all route or replacing
the regex catch-all rule with a PathPrefix catch-all rule.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
