Signalr client frequently getting 404 when trying to connect to ALB in AWS

[shaykeren]

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:
Forcing my client to use WebSockets and with SkipNegotiation=true [Works with no errors!]
Forcing my client to use LongPolling or ServerSentEvents and configure my application load balancer with Stickiness=true [Works with not errors!]
Configure my application load balancer with Stickiness=true and using the following code(without specifying any transport)
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?

I opened a discussion before opening this bug:
#23350

It looks to me like the .NET SignalR client isn't carrying forward the sticky sessions cookie on the upgrade to websocket request.
(see discussions for more details)

• ASP.NET Core version 3.1

[lscpike]

I've just had this same issue with a similar set up (behind a load balancer using cookies for sticky sessions).

I've tracked it down to the fact the CookieContainer isn't shared between the main HttpClient and the WebSocketClient by default.

See https://github.com/dotnet/aspnetcore/blob/master/src/SignalR/clients/csharp/Http.Connections.Client/src/HttpConnection.cs#L540.

A work around is to add any cookie to the container:

 _hubConnection = new HubConnectionBuilder()
                .WithUrl(url, opts =>
                {
                    opts.UseDefaultCredentials = true;
                    opts.Cookies.Add(new Cookie("ForceCookie", "NA", "/", url.DnsSafeHost));
                })

Obviously this needs fixing properly.