I think a strict superset is difficult to define. We may start from a simple way to do it.
Chao Zhang https://github.com/tokers On November 19, 2021 at 15:50:34, Li Yang ([email protected]) wrote: Hello, Community, Currently in APISIX, there is a built-in prioritization of routes by the matching uri. For example, if the requested uri is /foo/bar, and the server side routes contain /foo/bar and /foo/* and /*. Although all 3 uri patterns match /foo/bar, only the exact match /foo/bar will be chosen. That design makes much sense since a stricter route takes priority than a looser one. But when we have route matching on fields other than uri, the priority will only depend on the priority field. For example, consider 2 routes: { "name": "route1", "uri": "/_graphql", "vars": [ ["graphql_operation", "==", "query"], ["graphql_name", "==", "getRepo"], ["graphql_root_fields", "has", "owner"] ], "upstream": { "type": "roundrobin", "nodes": { "39.97.63.215:80": 1 } } } and { "name": "route2", "uri": "/_graphql", "upstream": { "type": "roundrobin", "nodes": { "39.97.63.215:81": 1 } } } A request which matches both route1 and route2 will possibly hit route2 since we don't have prioritization on vars. Although priority setting can help here, if a big organization shares the same APISIX, it will be difficult for all the developers to agree on how to use the priorities since every priority itself can impact others in an unexpected way. Here I want to propose that we provide a smart prioritization: * If route X and route Y share the same URI, their priority will be determined like this: * * Route X should be matched first if and only if route X's matching rule set is a proper superset of route Y's matching rule set.* Relevant discussion: https://github.com/apache/apisix/issues/3865
