Failed to match Route configuration for upstream path using catchAll, everything ...

[xingwen1987]

Steps to Reproduce the Problem

1. Config the ocelot.json file as follows: ocelot.json
2. visit /gateway/Listen route, ocelot fine to route and return data in localhost and docker
3. using SignalR Client to visit route, in localhost, it's fine, 4.but run in docker, same config, thorw follow exception: requestId: 0HM3VRDIC177A:00000001, previousRequestId: no previous request id, message: Error Code: UnableToFindDownstreamRouteError Message: Failed to match Route configuration for upstream path: /notify/negotiate, verb: POST. errors found in ResponderMiddleware. Setting error response for request path:/notify/negotiate, request method: POST My Question is, why i set "DownstreamPathTemplate": "/notify/{catchAll}" and "UpstreamPathTemplate": "/gateway/notify/{catchAll}", Ocelot failed to match the route in docker.

Specifications

• Version:16.0.1
• Platform:.net core 3.1 LTS
• Subsystem:windows 10 / docker on centos 7

[jlukawska]

Hello, as I see in the logs it seems that you use /gateway/notify/negotiate on the localhost, and /notify/negotiate on the docker.

[xingwen1987]

Hello, as I see in the logs it seems that you use /gateway/notify/negotiate on the localhost, and /notify/negotiate on the docker.

the address www.xxx.com:7001 is a Signalr stand-alone remote service. The meaning of the first picture is to mount the remote Signalr service in the local environment, Ocelot can be routed and forwarded normally. In the second picture, what I want to express is that after Ocelot is released to docker, the same configuration can no longer be routed normally.

[jlukawska]

If you have: "UpstreamPathTemplate": "/gateway/notify/{catchAll}" in configuration, Ocelot won't find /notify/negotiate neither on the local machine, nor in the docker container, because there is no match. It looks like you're testing /gateway/notify/negotiate on the local machine and /notify/negotiate in the docker container.

[imnotwannafire]

Hello, as I see in the logs it seems that you use /gateway/notify/negotiate on the localhost, and /notify/negotiate on the docker.

the address www.xxx.com:7001 is a Signalr stand-alone remote service. The meaning of the first picture is to mount the remote Signalr service in the local environment, Ocelot can be routed and forwarded normally. In the second picture, what I want to express is that after Ocelot is released to docker, the same configuration can no longer be routed normally.

Hi, have u solve this issue ? I'm struggling at this point too. Could you share how to fix it

[roselle11111]

i have the same issue any updates? thank you

[Lvantin]

I got the same problem. This is what I configured for the gateway "ReRoutes": [ { "DownstreamPathTemplate": "/{everything}", "DownstreamScheme": "https", "DownstreamHostAndPorts": [ { "Host": "localhost", "Port": 5000 }, { "Host": "localhost", "Port": 5001 } ], "UpstreamPathTemplate": "/Account/{everything}", "LoadBalancerOptions": { "Type": "LeastConnection" }, "UpstreamHttpMethod": [ "Put", "Delete", "Get", "Post" ] } ]

The idea is that when user access like https://localhost:9000/Account/GetUserList ==> Ocelot will redirect to https://localhost:5000/GetUserList OR https://localhost:5001/GetUserList

I have configured this way and it ran perfectly on previous version of Ocelot. Recently, I changed to .NET5 and update libraries. It did not work.

I created very simple project, just keep Ocelot in the init ==> It did not work too. I had no clues to solve it.

[kgrosvenor]

Any updates, it wont work on .net 6/7 in my case

I get must be a ws or wss:// url as though its not translating the tranport properly, it tries to connect in gateeway as a http url

[raman-m]

@kgrosvenor

First,

Regarding wss-protocol. Do you know this protocol is not supported by Ocelot? Yeah, I see, it is 2023 year when the people uses Web 3 protocols, and all modern browsers support latest specs of Web Sockets, HTTP2, HTTP3 protocols. Nowadays unfortunately Ocelot does not support latest Web Sockets, SignalR protocols. Ocelot has limited support of Web Socket old specs (ws-protocol, not encrypted). But you have to use old 15, 16 releases with old .NET releases (.NET 3.1 and .NET 5). Probably Websockets feature in Ocelot v19 (.NET 7) is unstable. Acceptance tests are green, but you should not consider this fact as Websockets feature works corrrectly in Ocelot this 2023 year. We have a huge missing here. Much effort is needed to implement modern protocols: Web Socket, SignalR. We must understand that during these last 3-4 years Microsoft has been released .NET 5, .NET 6 and .NET 7 versions. So, .NET SDK software has changed. The System.Net namespace has been changed a lot. Currently the community has pointed to this Web Socket problem multiple times. See:

• 930

• 1636

• and etc...

Please, stop any experiments with wss-protocols! You can use http and https protocols only. The ws & SignalR protocols are supported partially by legacy specs.

Second,

Here are more technical details and explanations. I believe Ocelot supports WebSocket unencrypted (aka "ws" protocol) In docs we have the page: Websockets From paragraphs of this page we can see that Ocelot supports WS-protocol and SignalR (legacy v1.0.2) only. Having browse and search through source code I have found nothing related to "wss" protocol (aka WebSocket encrypted). It seems Ocelot does not support WSS, SignalR latest. Also, there are 0 references to Microsoft.AspNetCore.SignalR.Client package! That's strange! Currently we are referencing web socks client via the System.Net.WebSockets namespace. An we use the ClientWebSocket class in WebSocketsProxyMiddleware. The System.Net.WebSockets.Client assembly is implicitly referenced by .NET 7 Web App.

Finally,

I am afraid that Ocelot has no support for wss-protocol via "DownstreamScheme": "wss" option.

[raman-m]

@xingwen1987 Hi Richfiter! Are you still with Ocelot in 2023? 😸 We have new release v19.0.2 based on .NET 7

[raman-m]

Dear @xingwen1987, Upgrade to the latest version 23.3.0!

You have the right to reopen this issue in the future if you come with a PR ready