Catch-all routes don't use Priority 0 by default (despite documentation implying that they do)

[aschuhardt]

Expected Behavior

Refer to this part in the documentation:

0 is the lowest priority, Ocelot will always use 0 for /{catchAll} Routes and this is still hardcoded. After that you are free to set any priority you wish.

Based on this information, I assumed that I could omit the "Priority" option on catch-all routes (because it's hard-coded to be zero, right?) and that route matching would work identically to if I had explicitly set the priority to 0.

Given the configuration shown below, therefore, I would expect the route /api/test/hello not to resolve the catch-all route. I expect this because I explicitly set the second (non-catch-all) route to have a Priority of 1, so it should take priority.

{
  "Routes": [
    {
      "DownstreamPathTemplate": "/test/{everything}",
      "DownstreamScheme": "http",
      "DownstreamHostAndPorts": [
        {
          "Host": "localhost",
          "Port": 5000
        }
      ],
      "UpstreamPathTemplate": "/api/test/{everything}",
      "UpstreamHttpMethod": ["GET"]
    },
    {
      "DownstreamPathTemplate": "/test",
      "DownstreamScheme": "http",
      "DownstreamHostAndPorts": [
        {
          "Host": "localhost",
          "Port": 5000
        }
      ],
      "UpstreamPathTemplate": "/api/test/hello",
      "UpstreamHttpMethod": [ "GET" ],
      "Priority": 1 
    }
  ],
  "GlobalConfiguration": {
    "BaseUrl": "https://localhost:5000"
  }
}

Actual Behavior

Given the above example configuration, the route /api/test/hello does match on the catch-all route for some reason. This is not what I expected after reading the documentation, since I would expect the first route (the catch-all) to have a Priority of 0, and the second to have a Priority of 1.

Once I add "Priority": 0 to the catch-all route, however, the Priority feature seems to begin operating as expected, and /api/test/hello resolves to the non-catch-all route.

So, it seems that either the default priority for catch-all routes is not zero, or that some other issue is at play.

It would be good if either the documentation was updated to clarify this point, or if the routing behavior was updated to match the behavior implied by the documentation.

Steps to Reproduce the Problem

1. Extract the and run ASP.NET project attached to this issue, or set up a new project with a configuration similar to that shown above.
2. Run the project and navigate to http://localhost:5000/api/test/hello; this is the catch-all route, and returns the argument 'hello'.
3. Add "Priority": 0 to the catch-all route in ocelot.json.
4. Again run the project and navigate to http://localhost:5000/api/test/hello. Notice that the non-catch-all route is now being resolved.

Specifications

• Version: 17.0.0
• Platform: Windows 10 64-bit

[raman-m]

Hi Addison!
Could you upgrade to the latest version 22.0.1 and confirm the issue still persists please?

[aschuhardt]

I'm afraid not, as I've since switched employers and no longer use this. Thank you though!

…

On January 28, 2024 11:32:40 AM UTC, Raman Maksimchuk ***@***.***> wrote: Hi Addison! Could you upgrade to the latest version **22.0.1*" and confirm the issue still persists please? -- Reply to this email directly or view it on GitHub: #1504 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

[raman-m]

@aschuhardt commented Jan 28, 2024

I'm guessing your next employer uses other gateway products, right?
In any case, I think your user scenario is quite interesting in terms of the prioritization feature. Yes, it looks like you want an exclusive static route with the highest priority. We can take this idea further, I'm going to reopen this issue...
The problem is that the exclusive route is implicitly included in Catch-All one. So, we can review our "downstream path matching" logic...
Let me know if you would like to contribute.