Downstream route is not allowed to end on a forward slash

[LueNC]

Expected Behavior / New Feature

This is our route:

{
      "UpstreamHeaderTransform": {
        "Accept": "application/json"
      },
      "AuthenticationOptions": {
        "AuthenticationProviderKey": "Cookies",
        "AllowedScopes": []
      },
      "DelegatingHandlers": [
        "WebMailboxDelegatingHandler"
      ],
      "DownstreamPathTemplate": "/apis/v1/mailboxes/",
      "UpstreamPathTemplate": "/api/mailboxes",
      "DownstreamHeaderTransform": {
        "content-type": "application/json"
      },
      "DownstreamScheme": "https",
      "DownstreamHostAndPorts": [
        {
          "Host": "Censored",
          "Port": 443
        }
      ],
      "UpstreamHttpMethod": [
        "GET"
      ],
      "QoSOptions": {
        "ExceptionsAllowedBeforeBreaking": 10,
        "DurationOfBreak": 1000,
        "TimeoutValue":15000
      }
    }

I expect the UpstreamPath to be mapped to the DownstreamPath as per the template.

Actual Behavior / Motivation for New Feature

The last forward slash is removed, thus resulting in a 404 for our end as the last forward slash is expected.
This used to work but for some reason this code was added to the DownstreamURLCreatorMiddleware

var dsPath = response.Data.Value; 
if (dsPath.EndsWith(Slash) && !upstreamPath.EndsWith(Slash)) 
{
    dsPath = dsPath.TrimEnd(Slash);
    response = new OkResponse<DownstreamPath>(new DownstreamPath(dsPath));
}

in this commit: #1911

Steps to Reproduce the Problem

Specifications

• Version: 23.2.2
• Platform: Windows server 2012
• Subsystem:

[Raman Maksimchuk]

Fix 1

      "DownstreamPathTemplate": "/apis/v1/mailboxes/",
      "UpstreamPathTemplate": "/api/mailboxes/",

Fix 2

      "DownstreamPathTemplate": "/apis/v1/mailboxes/?fake=bla-bla",
      "UpstreamPathTemplate": "/api/mailboxes/",

[LueNC]

@raman-m We should not need a workaround for something that has worked since Ocelot 15. Is there any reason that it is desirable to not allow an ending backslash?

[Raman Maksimchuk]

Docs

• Placeholders
• Empty Placeholders
• Catch All
• Query String Placeholders

We should not need a workaround for something that has worked since Ocelot 15.

The Ocelot project evolves, my dear!
If you need old behavior, don't upgrade the version! Stay on version 15.x!!!

Is there any reason that it is desirable to not allow an ending backslash?

Once again: Empty Placeholders
It allows slashes if you define the following Catch All route:

      "DownstreamPathTemplate": "/apis/v1/mailboxes/{catchAll}",
      "UpstreamPathTemplate": "/api/mailboxes/{catchAll}",

Incoming URL path must be: /api/mailboxes/, note with slash!
Then the downstrean URL path will be: /apis/v1/mailboxes/, note with slash!

Hope it helps!