AFAIK, in this case, the logical operator of the elements in route1's vars is and, the request must reach these three conditions before it will be captured by route1. so it has nothing to do with route2's vars.
*ZhengSong Tu* My GitHub: https://github.com/tzssangglass Apache APISIX: https://github.com/apache/apisix Li Yang <yan...@apache.org> 于2021年11月23日周二 下午4:01写道： > > Hi ZhengSong, > > Sure, I can give you an example. > > Suppose we have two 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 <http://39.97.63.215/>": 1 > } > } > } > > and > > { > "name": "route2", > "uri": "/_graphql", > "vars": [ > ["graphql_operation", "==", "query"] > ], > "upstream": { > "type": "roundrobin", > "nodes": { > "39.97.63.215:81": 1 > } > } > } > It's obvious route1's matching rules is a proper superset of route2's > matching rules, > so route1 should be the one with higher priority. > > On Mon, Nov 22, 2021 at 11:56 PM ZhengSong Tu <tzssanggl...@gmail.com> > wrote: > > > hi, yang. > > > > > 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.* > > > > I have doubts about this, can you show some example? > > > > *ZhengSong Tu* > > My GitHub: https://github.com/tzssangglass > > Apache APISIX: https://github.com/apache/apisix > > > > Chao Zhang <zchao1...@gmail.com> 于2021年11月22日周一 下午3:44写道： > > > > > > > > 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 (yan...@apache.org) 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 > >
