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 <[email protected]>
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 <[email protected]> 于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 ([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
>
