Replies: 4 comments 14 replies
-
That's strange, does it fallback from websockets? |
Beta Was this translation helpful? Give feedback.
-
What compute power are you putting behind the load balancer? Containers, Windows EC2 instances or Linux EC2 instances? If it is a Linux environment is the load balancer going straight to Kestrel or do you have an Nginx reverse proxy in between? |
Beta Was this translation helpful? Give feedback.
-
I'm able to reproduce the problem and it does seem to be error with stick sessions not being honored correctly since I can't reproduce the issue when their is only one instance behind the load balancer. It looks to me like the .NET SignalR client isn't carrying forward the sticky sessions cookie on the upgrade to websocket request. Here is the raw request for the POST negotiate:
and the response contains cookies ALB uses for tracking sticky sessions
The response contains the
Here is the failure response
I do see subsequent request passing along the Cookies but I assume that is when it is falling back to other protocol.
|
Beta Was this translation helpful? Give feedback.
-
So the stickiness is mandatory only for the Signalr negotiation phase? |
Beta Was this translation helpful? Give feedback.
-
Trying to connect Signalr client written with c# (netcoreapp 3.1 console application) toSignalr service running on two instances of WebAPI (netcoreapp3.1) behind application load balancer in AWS.
Frequently I'm getting the following error:
Unable to connect to the server with any of the available transports. (WebSockets failed: The server returned status code '404' when status code '101' was expected.) (ServerSentEvents failed: Response status code does not indicate success: 404 (Not Found).) (LongPolling failed: Response status code does not indicate success: 404 (Not Found).)
I noticed the following behaviors:
var connection = new HubConnectionBuilder() .WithUrl($"{host}/hub/agent") .WithAutomaticReconnect() .Build(); await connection.StartAsync();
[Works with no error!] BUT the selected transport will be set to ServerSentEvents all the time.My Question is Why Can't I use WebSocket without defining the SkipNegotiation=true in my environment?
Thanks
Beta Was this translation helpful? Give feedback.
All reactions