Placeholder value does not correctly replace when the placeholder is defined between round braces

[PratikPatel-Mtech]

Expected Behavior

The specified placeholder variable value should be replaced within the Downstream URI provided in the UpstreamPathTemplate and DownStreamPathTemplate. For instance,

Route Configurations:

{
  "DownstreamPathTemplate": "/api/subscriptions({subscriptionId})/updates",
  "UpstreamPathTemplate": "/v1/subscriptions({subscriptionId})/updates",
  "UpstreamHttpMethod": [ "Get" ],
  "DownstreamScheme": "http",
  "DownstreamHostAndPorts": [
    { "Host": "localhost", "Port": 50110 }
  ]
}

When the request URI is http://localhost:5001/v1/subscriptions(123)/updates
Then the downstream request URI should be http://localhost:50110/api/subscriptions(123)/updates

Actual Behavior

It's adding extra round braces ) in the Downstream request. It's a clear issue of replacing placeholder variables.

When the request URI is http://localhost:5001/v1/subscriptions(123)/updates
Then the downstream request URI is http://localhost:50110/api/subscriptions(123))/updates

Steps to Reproduce the Problem

1. Add a route with the placeholder within the round braces
2. Get parameter value in the downstream. Observed the value received at the downstream application.

NOTE: An issue is not with specific round braces. It reproduces with any other routes where the placeholder does not exactly(eg. /{id}/ ) provide between slashes.

Specifications

• Version: 17.0.0
• Platform: .NET 5

[ks1990cn]

@PratikPatel-Mtech Looks like this is from Microsoft aspnet inbuilt thing for Placeholder Value comming through HttpContext.

But its really strange to note that from swagger for these routes we get right result.

probably swagger can implement this as it has UI for input, but from postman its tough to find any specific pattern. Example from swagger /su((!))/row is valid for route /su({string}/row

@raman-m @ggnaegi Any thoughts on this?

[raman-m]

@PratikPatel-Mtech Hi Pratik,
Thanks for reporting!

We will check this... Too busy...
Do you have intention to write unit tests or acceptance one in your fork?
Please, fork Ocelot repo and in some feature branch you can write tests...

By this way you will confirm that the bug still exists in current version 20.0