Query parameter names containing id are corrupted when another route has {id} placeholder (Regression in 23.4.3)

[bhargav-polara]

After upgrading to Ocelot 23.4.3, query parameters whose names contain the substring id (e.g. customer_id) are incorrectly rewritten when another route with a {id} path parameter exists.

This causes query parameters to be corrupted and forwarded incorrectly to downstream services.

Routes Configuration

{
  "Routes": [
    {
      "UpstreamPathTemplate": "/finance/v1/payment-methods/{id}",
      "UpstreamHttpMethod": [ "Get" ],
      "DownstreamPathTemplate": "/v1/payment-methods/{id}",
      "DownstreamScheme": "http",
      "DownstreamHostAndPorts": [
        {
          "Host": "localhost",
          "Port": 5003
        }
      ]
    },
    {
      "UpstreamPathTemplate": "/finance/v1/payment-methods",
      "UpstreamHttpMethod": [ "Get" ],
      "DownstreamPathTemplate": "/v1/payment-methods",
      "DownstreamScheme": "http",
      "DownstreamHostAndPorts": [
        {
          "Host": "localhost",
          "Port": 5003
        }
      ]
    }
  ]
}

Steps to Reproduce

Call the second route with a query parameter:
GET /finance/v1/payment-methods?customer_id=5172980

Expected Behavior

Downstream request:
/v1/payment-methods?customer_id=5172980

Query parameters must remain unchanged.

Actual Behavior

Ocelot rewrites the query parameter:
/v1/payment-methods?customer5172980

The id substring in customer_id is incorrectly treated as a route token and removed.

Ocelot Version

• 23.4.3

Previously Working

• Yes (22.x and earlier 23.x)

[bhargav-polara]

@raman-m Just following up on this issue to check if there’s any update or guidance available.

[raman-m]

Hello, Bhargav!

Just following up on this issue to check if there’s any update or guidance available.

Guidance on what exactly? Development or logic explanations?
Can you submit a bugfix pull request? Are you a C# developer? I don’t see any public .NET projects in your repositories.
If we take on this issue, the first step to fix the bug is to fork the Ocelot repository to your account. After that, just follow Ocelot’s development process.

It could be a bug, given that Ocelot's routing feature logic is quite complex. Honestly, I can't pinpoint the root cause, but I suspect faulty logic in the DownstreamUrlCreatorMiddleware. The issue might be in the MergeQueryStringsWithoutDuplicateValues method 👇

Ocelot/src/Ocelot/DownstreamUrlCreator/DownstreamUrlCreatorMiddleware.cs

Line 98 in 9fc4e78

protected static string MergeQueryStringsWithoutDuplicateValues(string queryString, string newQueryString, List<PlaceholderNameAndValue> placeholders)

But finally, I am not sure...

[raman-m]

Ocelot Version

• 23.4.3

Previously Working

• Yes (22.x and earlier 23.x)

So, why not upgrade to version 24.1.0 ?

[raman-m]

Your ocelot.json has 2 routes:

      "UpstreamPathTemplate": "/finance/v1/payment-methods/{id}",
      "UpstreamPathTemplate": "/finance/v1/payment-methods",

Well... I am curious, why did you define the 2nd route?

Since Ocelot can handle all URLs, including empty placeholders, your JSON config should have a single route with /finance/v1/payment-methods/{id} as the upstream, as empty placeholder URLs are already covered by the first route.

So, streamline your configuration by using just one route.

[raman-m]

Steps to Reproduce

Call the second route with a query parameter: GET /finance/v1/payment-methods?customer_id=5172980

Expected Behavior

Downstream request: /v1/payment-methods?customer_id=5172980
Query parameters must remain unchanged.

Actual Behavior

Ocelot rewrites the query parameter: /v1/payment-methods?customer5172980
The id substring in customer_id is incorrectly treated as a route token and removed.

Got it! Could you try experimenting with an upstream that uses a Catch All Query String like:

{
  "UpstreamPathTemplate": "/finance/v1/payment-methods?{query}",
  "DownstreamPathTemplate": "/v1/payment-methods?{query}"
}

Would the bug still be active with this kind of upstream template? Please share the test results.

[bhargav-polara]

@raman-m I had tested the catch-all query approach (?{query}), and it does preserve the query correctly. However, it doesn’t work for routes with path placeholders and feels more like a workaround than a fix.

The issue appears to be that placeholder replacement is matching substrings (e.g., id in customer_id) instead of exact tokens, likely in RemoveQueryStringParametersThatHaveBeenUsedInTemplate. after this change its breaking