Downstream route is not allowed to end on a forward slash about ocelot HOT 7 CLOSED

@raman-m absolutely deplorable to introduce such a breaking change and offering no backwards compatibility.

And why is this not communicated at all on the release notes?

from ocelot.

@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?

from ocelot.

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!

from ocelot.

Fix 1

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

Fix 2

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

from ocelot.

@sybren9 What's up?

from ocelot.

Dear @sybren9,

Please be aware that Ocelot is open-source software, available at no cost, and as such, your judgment as a customer does not apply❗

such a breaking change

I believe that making requests with an invalid URL does not constitute a breaking change, as any HTTP tool can encounter an error. Additionally, I want to convey to Ocelot's enthusiasts that using invalid URLs to judge the validity of a configuration is not the correct approach.

The version 23 Empty Placeholders feature has been implemented and the corresponding documentation is now available.

offering no backwards compatibility.

The author highlighted a unique case where the absence of a trailing slash caused one of the many downstream services to fail, though the reason was not provided. It's important to understand that the Ocelot team cannot be held accountable for the instability of downstream services utilized by the community. Predicting how a new version will affect the behavior of downstream services is challenging and often not feasible. Community feedback is vital in monitoring backward compatibility. Rather than guaranteeing strict backward compatibility, we suggest a gradual migration of the solution through a review of the configuration, simply by updating the ocelot.json file.

And why is this not communicated at all on the release notes?

Have you read our 23.0.0 Release Notes at all?
See Focus On → Middlewares → DownstreamUrlCreatorMiddleware with the note:

• DownstreamUrlCreatorMiddleware: Fixed bug for ending/omitting slash in path templates aka Empty placeholders feature by @AlyHKafoury

This scenario presents a classic dilemma: on one hand, the community desires bug fixes and new behaviors, while on the other, the new feature impacts routing. As the product owner, I have the authority to determine the product's evolution. I believe that the new functionalities in #748 and #1911 will benefit the community due to the high level of interest, despite the potential effects on backward compatibility.

P.S.

Every major version update typically requires testing and possibly stabilization based on community feedback, which is a standard part of the natural Software Development Life Cycle (SDLC).
Beyond the standard stabilization phase, we advise smooth migrations following valuable and reasonable discussions.

from ocelot.

@sybren9
While reviewing your contribution to our project, it turned out that your contribution was missing. 👉

• No commits means no contributions
• No issues means no help to improve the project
• No pull requests means no possible contributions
• No discussions means your low interest in our product

But you judge❗🤯

In my view, debating the backward compatibility of an OSS product is only justifiable if the user has made contributions; unfortunately, you have not.

from ocelot.