attempts to access wss:// with error

[guylando]

Using rtm-30733 version (I think it appeared after upgrading to this version from preview2-final).

While most of the time connects to https:// sometimes there is the following error in chrome console:
WebSocket connection to 'wss://xxx.com/rt?id=9kp2yWEewuI_REpPZeSWsg' failed: Error during WebSocket handshake: Unexpected response code: 404

it attempts from some reason to connect to wss:// instead of https://

and 404 is returned because of that

[davidfowl]

It’s becuse the behavior to skip negotiation changed . You don’t have sticky sessions turned on and if you don’t want that then you need to skipNegotiation by setting the option when using the HubConnectionBuilder

[davidfowl]

var connection = new signalR.HubConnectionBuilder()
                           .withUrl("/chat", { skipNegotiation: true, transport: signalR.HttpTransportType.WebSockets })
                           .build();

[guylando]

Thanks,
I will check for a couple of days if this solved it and we dont observe the errors anymore

[guylando]

I didnt want to specify only websockets transport because I want to have fallbacks.

I got this error:
Error: Failed to start the connection: Error: Negotiation can only be skipped when using the WebSocket transport directly.

what if I want to have transport fallbacks and yet not to have the wss:// request error?

[davidfowl]

Then you need sticky sessions.

[analogrelay]

Are you using Azure App Service? If so, you need to enable the "ARR Affinity" option in the Portal. SignalR requires that each client always connects to the same server for the duration of the request. You do this by configuring your Load Balancer to always route requests from the same "session" to the same server. In Azure App Service this is "ARR Affinity", but other environment may have other terms for it.

[guylando]

We will use load balancer soon so I wrote to myself regarding ARR Affinity, thanks.

I am sorry but I don't fully know the sticky sessions term in this aspect. Is there some signalr flag to turn this on? If it requires some complicated change then I guess just having the wss:// error in console is something not that bad instead of doing complicated changes. Why doesn't the negotiation happen again as in the beginning, on the second time without going to wss://? or maybe is there some flag to tell signalr to reconnect using full renegotiation which would eliminate this?

[analogrelay]

To clarify, are you using a single server and seeing this problem? You shouldn't see this issue in a single-server environment. Can you provide log messages and network traces as requested in the Issue Template: https://github.com/aspnet/SignalR/blob/dev/.github/ISSUE_TEMPLATE.md ?

[analogrelay]

Closing this as we haven't heard from you. Please feel free to comment if you're able to get the information we're looking for and we can reopen the issue if we're able to identify the problem.