Disable non-websocket transports for Blazor Server

[danroth27]

Customers often have a bad time if they use Blazor Server with transports other than websockets. We should consider disabling non-websocket based transports for Blazor Server apps and provide a good error experience when websockets are not available.

[ghost]

Thanks for contacting us.

We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[pranavkm]

FYI @BrennanConroy / @davidfowl

[BrennanConroy]

We should consider disabling non-websocket based transports

If you do this you need to make sure that there is a way to opt back into other transports. You don't want to exclude those customers that can't run WebSockets for whatever reason.

Do you have ideas of how to surface clean errors for this or is there asks for SignalR to help here?

[danroth27]

Some evidence of Blazor Server usage over non-websockets: https://twitter.com/HeyWellsy/status/1408275567489601540

[TanayParikh]

provide a good error experience when websockets are not available.

@danroth27 Did you have anything in mind to ensure a 'good error experience'? Would a banner with a message like the following be appropriate?

@javiercn

[javiercn]

@TanayParikh can you detect that the websocket failed to connect?

[TanayParikh]

@TanayParikh can you detect that the websocket failed to connect?

Yep, I'm able to catch the following exception:

Error: Unable to connect to the server with any of the available transports. WebSockets failed: Error: 'WebSockets' is not supported in your environment.

Hence we can give a pretty specific error message about WebSockets being unavailable.

[BrennanConroy]

I don't think that is the right error for this scenario. How did you get that?

[TanayParikh]

I don't think that is the right error for this scenario. How did you get that?

Running a basic script in my browser (before page load) that does:

WebSocket2 = null;
WebSocket = null;

Is it possible to use:

aspnetcore/src/SignalR/clients/ts/signalr/tests/HttpConnection.test.ts

Line 252 in fd85422

WebSocket: WebSocketNotAllowed,

for browser testing as well?

[BrennanConroy]

Running a basic script in my browser (before page load) that does:

Ok, so that tests old un-supported browsers that don't support WebSockets at all. You also need to test connecting to a server that doesn't support WebSockets, which will be a slightly different error

for browser testing as well?

Yes

[TanayParikh]

You also need to test connecting to a server that doesn't support WebSockets, which will be a slightly different error

I'm assuming this is with client side enforcing WebSockets transports layer, in which case I emulated that now via:

options.Transports = HttpTransportType.LongPolling

and got:

 Error: Failed to start the connection: Error: Unable to connect to the server with any of the available transports. LongPolling failed: Error: 'LongPolling' is disabled by the client.

I believe the underlying "ability" to detect WS not being available isn't hindered. Will ensure the final solution reflects both these use cases.