Blazor Disable Non-WebSockets Transports by Default #34644

TanayParikh · 2021-07-23T16:11:58Z

This PR makes WebSockets the default HTTPTransportType.

Scenarios

Client	Server	Message
WS (without browser WS support)	WebSockets	`Unable to connect, please ensure you are using an updated browser that supports WebSockets.`
WS (with WS connection being rejected)	WebSockets	`Unable to connect, please ensure WebSockets are available. A VPN or proxy may be blocking the connection.`
WS	LongPolling	`An unhandled error has occurred.` Console Error: `Unable to initiate a SignalR connection to the server. This might be because the server is not configured to support WebSockets. To troubleshoot this, visit https://aka.ms/blazor-server-websockets-error.`
LongPolling	WebSockets	`An unhandled error has occurred.`

See this conversation on the last two error messages being unnecessary.

Custom Configuration

Server Side

In Startup.cs, replace endpoints.MapBlazorHub() with:

endpoints.MapBlazorHub(configureOptions: options => 
{ 
    options.Transports = HttpTransportType.WebSockets | HttpTransportType.LongPolling; 
});

Client Side

Add the following script to _Layout.cshtml before the closing </body> tag. WebSockets (1) and Long Polling (4) are the supported HTTPTransportTypes.

<script>
    (function start() {
        Blazor.start({
            configureSignalR: builder => builder.withUrl('_blazor', 4) // Long Polling
        });
    })()
</script>

Fixes: #33775

TODO: E2E tests.

src/Components/Web.JS/src/Boot.Server.ts

pranavkm · 2021-07-23T16:19:24Z

@TanayParikh, presumably the overload that does not require a path also works:

 endpoints.MapBlazorHub(configureOptions: options => 
    { 
        options.Transports = HttpTransportType.WebSockets | HttpTransportType.LongPolling; 
    });

?

TanayParikh · 2021-07-23T16:23:40Z

@TanayParikh, presumably the overload that does not require a path also works:

Yep, you're absolutely right, will update the example. Thanks.

pranavkm · 2021-07-23T16:23:28Z

src/Components/Web.JS/src/Boot.Server.ts

+    return;
+  }
+
+  if (ex.message.includes(`'WebSockets' is not supported in your environment.`)) {


Would we be able to change SignalR to throw a type and use that here instead of string sniffing: https://developer.mozilla.org/en-US/docs/web/javascript/reference/statements/throw#throw_an_object?

cc/ @BrennanConroy would you be open to this change?

I'm not against throwing a specific error type at

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

Line 408 in 3eb0fa8

return Promise.reject(new Error(`Unable to connect to the server with any of the available transports. ${transportExceptions.join(" ")}`));

Much better than doing string matching since those can change at any time.

Just added a Error.name here:

e03d084#diff-757d83bcf707b34888c824c952e4717638803af7b5372f6c5da1eb838f1a5814R450-R452

Due to the way exception nesting is done in the HttpConnection, having the name itself propagate up would likely require a lot more extensive changes. Instead, I'm still relying a bit on string sniffing, but I'm sniffing the custom Error.name instead of the message.

e03d084#diff-7c47c684c78e3f5b5eeecb28b249b03afcefcd90a925cc20b69ec2cdec261752R134

What was wrong with changing the type of exception we throw?

If you're referring to here:

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

Line 408 in 3eb0fa8

return Promise.reject(new Error(`Unable to connect to the server with any of the available transports. ${transportExceptions.join(" ")}`));

Several different issues can result in an exception being thrown there. So changing the exception type being thrown there wouldn't provide us with specific enough information (ie. diagnose a WS failed connection).

If it's for changing the exception type here instead of the name:
e03d084#diff-757d83bcf707b34888c824c952e4717638803af7b5372f6c5da1eb838f1a5814R451

I just wanted to avoid adding an additional exception type when the spec compliant Error.name would be sufficient for our purposes. Let me know if you feel otherwise and I can add it in.

Updated 895afb2.

BrennanConroy · 2021-07-23T17:33:22Z

builder.withUrl('_blazor', 4)

That's unfortunate 😢 would be nicer if you could do builder.withTransport(4) or something similar.

(Yes I know that's SignalR's fault)

src/Components/Web.JS/src/Boot.Server.ts

TanayParikh · 2021-07-25T19:21:14Z

E2E tests added, ready for review / merging.

src/Components/Web.JS/src/Boot.Server.ts

src/Components/test/testassets/TestServer/Pages/Transports.cshtml

pranavkm · 2021-07-26T16:09:49Z

src/Components/test/testassets/TestServer/Pages/Transports.cshtml

+                builder.configureLogging("debug") // LogLevel.Debug
+                        .withUrl('_blazor',
+                        {
+                            WebSocket: WebSocketNotAllowed,


Same for this one. A much more useful test is to have the server disable websockets which would simulates a misconfigured server.

I'm inclined to keep this test as:

WebSocketNotAllowed approach should effectively be the same as the server rejecting a websocket request

I'd discussed testing VPN/proxy issues blocking WebSockets with Brennan, and this was the testing approach suggested. It's part of SignalR's testing mechanism that we're leveraging.

pranavkm

This is looking good. Feel free to IM me if you'd like to hash out the details.

src/Components/Web.JS/src/Boot.Server.ts

src/Components/test/testassets/TestServer/Pages/Transports.cshtml

src/SignalR/clients/ts/signalr/src/HttpConnection.ts

…nLongPolling

TanayParikh · 2021-07-26T23:15:32Z

Breaking Change Announcement: aspnet/Announcements#470

src/Components/Web.JS/src/Boot.Server.ts

src/Components/test/testassets/TestServer/Pages/Transports.cshtml

pranavkm · 2021-07-26T23:41:34Z

src/Components/test/testassets/TestServer/TransportsServerStartup.cs

+                    {
+                        options.Transports = Microsoft.AspNetCore.Http.Connections.HttpTransportType.LongPolling;


Co-authored-by: Pranav K <[email protected]>

BrennanConroy · 2021-07-27T16:03:51Z

src/SignalR/clients/ts/signalr/src/HttpConnection.ts

@@ -650,6 +651,45 @@ export class TransportSendQueue {
    }
 }

+class UnsupportedTransportError extends Error {


Error classes should go in https://github.com/dotnet/aspnetcore/blob/main/src/SignalR/clients/ts/signalr/src/Errors.ts

BrennanConroy · 2021-07-27T16:05:28Z

src/Components/Web.JS/src/Boot.Server.ts

+    if (ex.innerErrors && ex.innerErrors.some(e => e.errorType === 'UnsupportedTransportError' && e.transport === 'WebSockets')) {
+      showErrorNotification('Unable to connect, please ensure you are using an updated browser that supports WebSockets.');
+    } else if (ex.innerErrors && ex.innerErrors.some(e => e.errorType === 'FailedToStartTransportError' && e.transport === 'WebSockets')) {
+      showErrorNotification('Unable to connect, please ensure WebSockets are available. A VPN or proxy may be blocking the connection.');


Unable to connect, please ensure WebSockets are available.

Unable to connect, please ensure WebSockets are available on the server.

I'm not so sure about this as this message is end-user facing and hence I would like to avoid "on the server" as it has no end user configurability. Additionally, it may not be a server issue if the local client VPN/proxy is blocking the connection.

BrennanConroy · 2021-07-27T16:12:06Z

src/Components/Web.JS/src/Boot.Server.ts

+      showErrorNotification('Unable to connect, please ensure WebSockets are available. A VPN or proxy may be blocking the connection.');
+    } else if (ex.innerErrors && ex.innerErrors.some(e => e.errorType === 'DisabledTransportError' && e.transport === 'LongPolling')) {
+      logger.log(LogLevel.Error, 'Unable to initiate a SignalR connection to the server. This might be because the server is not configured to support WebSockets. To troubleshoot this, visit https://aka.ms/blazor-server-websockets-error.');
+      showErrorNotification();


Why doesn't this one get a nice UI message?

This represents the case when the client is attempting WS and the server only supports long polling. There's no remedial action the end-user can take here so we just present the generic "Unhandled exception has occurred". Note the developer will be presented a message to check the console and they'll see this error message to resolve the issue.

* Revert Enforce WebSockets Transport for Blazor (changes introduced in #34644) * Updated Release JS Files

* [release/6.0-rc2] Update dependencies from dotnet/efcore (#36635) [release/6.0-rc2] Update dependencies from dotnet/efcore * [release/6.0-rc2] Handle JsonExceptions in RequestDelegateFactory (#36627) * Handle JsonExceptions like InvalidDataExceptions in RequestDelegateFactory * Don't catch InvalidDataExceptions when reading JSON * [release/6.0-rc2] Update dependencies from dotnet/runtime dotnet/efcore (#36651) [release/6.0-rc2] Update dependencies from dotnet/runtime dotnet/efcore * Avoid using invalid content type for ValidationProblemDetails (#36618) Co-authored-by: Safia Abdalla <[email protected]> * Update dependencies from https://github.com/dotnet/efcore build 20210917.6 (#36667) [release/6.0-rc2] Update dependencies from dotnet/efcore * Use a fake clock in the test (#36626) Co-authored-by: Chris R <[email protected]> * Update dependencies from https://github.com/dotnet/runtime build 20210917.8 (#36675) [release/6.0-rc2] Update dependencies from dotnet/runtime * [release/6.0-rc2] Throw for invalid TryParse and BindAsync (#36662) * Backport of #36628 to release/6.0-rc2 * Throw for invalid TryParse and BindAsync * nit * use TypeNameHelper * nit Co-authored-by: Brennan <[email protected]> * Update dependencies from https://github.com/dotnet/efcore build 20210917.8 (#36681) [release/6.0-rc2] Update dependencies from dotnet/efcore * Revert Enforce WebSockets Transport for Blazor (#36656) * Revert Enforce WebSockets Transport for Blazor (changes introduced in #34644) * Updated Release JS Files * [release/6.0-rc2] Update dependencies from dotnet/runtime dotnet/efcore (#36687) [release/6.0-rc2] Update dependencies from dotnet/runtime dotnet/efcore * Update dependencies from https://github.com/dotnet/runtime build 20210917.25 (#36699) [release/6.0-rc2] Update dependencies from dotnet/runtime * Update dependencies from https://github.com/dotnet/efcore build 20210917.18 (#36701) [release/6.0-rc2] Update dependencies from dotnet/efcore * [release/6.0-rc2] Update dependencies from dotnet/efcore dotnet/runtime (#36706) [release/6.0-rc2] Update dependencies from dotnet/efcore dotnet/runtime * [Release/6.0-rc2] Fix and test HttpSys delegation (#36698) * Out of proc delegation tests * Troubleshoot IsFeatureSupported * Fix test * Fix formatting * Seperate tests * Cleanup * Fix SLN * Update dependencies from https://github.com/dotnet/efcore build 20210918.7 (#36715) [release/6.0-rc2] Update dependencies from dotnet/efcore * Find inherited TryParse and BindAsync (#36694) Co-authored-by: Brennan <[email protected]> * [release/6.0-rc2] Use minimal APIs for F# project templates (#36660) * [release/6.0-rc2] Retarget DOTNETHOME when installing x64 on ARM64 (#36695) * Retarget DOTNETHOME when installing x64 on ARM64 * Make platform comparison case insenstive * Address feedback * Install x64 registry keys to different path on ARM64 machine Co-authored-by: Eric StJohn <[email protected]> * Pin analyzers that ship in the SDK (#36690) (#36754) * Pin analyzers that ship in the SDK (#36690) * Pin analyzers that ship in the SDK ASP.NET Core produces a few analyzer assemblies that are shipped as part of the .NET SDK. These analyzers are added to web projects targeting 3.1 and newer. In 6.0, we (unintentionally) bumped the version of Microsoft.CodeAnalysis that these projects referenced to a 4.0 version. This causes warnings when opening a 3.1 or 5.0 app in VS 2019 as it does not support these versions. Additionally update the version of Microsoft.CodeAnalysis.* packages used in tests, Razor, and framework analyzers that are only expected to run with VS 2020 to a more recent build. This is largely book-keeping, but allows us to write a test for file scoped namespaces. Fixes #36552 * Apply suggestions from code review * [release/6.0-rc2] Rename and consolidate "DelegateEndpoint" types (#36578) * Call AddEndpointsApiExplorer() in controllers Web API template (#36753) - backport of #36752 to release/6.0-rc2 Co-authored-by: DamianEdwards <[email protected]> * [release/6.0-rc2] Update dependencies from dotnet/efcore dotnet/runtime (#36769) [release/6.0-rc2] Update dependencies from dotnet/efcore dotnet/runtime * Update dependencies from https://github.com/dotnet/efcore build 20210920.20 (#36778) [release/6.0-rc2] Update dependencies from dotnet/efcore Co-authored-by: dotnet-maestro[bot] <42748379+dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: Stephen Halter <[email protected]> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Safia Abdalla <[email protected]> Co-authored-by: Chris R <[email protected]> Co-authored-by: Brennan <[email protected]> Co-authored-by: Tanay Parikh <[email protected]> Co-authored-by: Chris Ross <[email protected]> Co-authored-by: Eric StJohn <[email protected]> Co-authored-by: Pranav K <[email protected]> Co-authored-by: DamianEdwards <[email protected]>

Blazor Disable Non-WebSockets Transports by Default

c4b3a17

TanayParikh requested a review from a team as a code owner July 23, 2021 16:11

ghost added the area-blazor Includes: Blazor, Razor Components label Jul 23, 2021

TanayParikh commented Jul 23, 2021

View reviewed changes

src/Components/Web.JS/src/Boot.Server.ts Outdated Show resolved Hide resolved

TanayParikh requested review from javiercn and BrennanConroy July 23, 2021 16:17

Update dist .js files

fab2c82

pranavkm reviewed Jul 23, 2021

View reviewed changes

Added UnsupportedTransportWebSocketsError

e03d084

TanayParikh force-pushed the taparik/disableNonWSTransportsByDefault branch from 576ec75 to e03d084 Compare July 23, 2021 18:31

TanayParikh requested a review from halter73 as a code owner July 23, 2021 18:31

pranavkm reviewed Jul 23, 2021

View reviewed changes

src/Components/Web.JS/src/Boot.Server.ts Outdated Show resolved Hide resolved

TanayParikh added 3 commits July 23, 2021 16:32

Merge branch 'main' into taparik/disableNonWSTransportsByDefault

f1dbafc

Added FailedToStartTransportError

895afb2

E2E Tests

ce0ba7d

Updated async awaits

b2dc979

pranavkm reviewed Jul 26, 2021

View reviewed changes

TanayParikh and others added 4 commits July 26, 2021 12:23

Remove ErrorIfBrowserDoesNotSupportWebSockets

dfd0128

MultipleErrors Approach

3bb93eb

Always show error notification if connection.start throws

1c3e8f6

Merge branch 'main' into taparik/disableNonWSTransportsByDefault

221503a

pranavkm reviewed Jul 26, 2021

View reviewed changes

src/Components/Web.JS/src/Boot.Server.ts Show resolved Hide resolved

src/Components/test/testassets/TestServer/Pages/Transports.cshtml Outdated Show resolved Hide resolved

src/SignalR/clients/ts/signalr/src/HttpConnection.ts Outdated Show resolved Hide resolved

TanayParikh and others added 3 commits July 26, 2021 17:00

PR Feedback

b55777f

Fix transport failed exception handling

61a27b7

TransportsServerStartup && ErrorIfClientAttemptsWebSocketsWithServerO…

6b6c71e

…nLongPolling

TanayParikh requested a review from pranavkm July 26, 2021 22:50

Fix Build

5f8b828

TanayParikh enabled auto-merge (squash) July 26, 2021 23:17

TanayParikh disabled auto-merge July 26, 2021 23:18

pranavkm approved these changes Jul 26, 2021

View reviewed changes

Update src/Components/test/testassets/TestServer/Pages/Transports.cshtml

0668383

Co-authored-by: Pranav K <[email protected]>

TanayParikh enabled auto-merge (squash) July 27, 2021 00:09

TanayParikh mentioned this pull request Jul 27, 2021

Using Long Polling for Blazor Server dotnet/AspNetCore.Docs#22863

Closed

TanayParikh merged commit a09fc71 into main Jul 27, 2021

TanayParikh deleted the taparik/disableNonWSTransportsByDefault branch July 27, 2021 04:26

ghost added this to the 6.0-rc1 milestone Jul 27, 2021

guardrex mentioned this pull request Jul 27, 2021

Blazor 6.0 content tracking issue dotnet/AspNetCore.Docs#22045

Closed

41 tasks

BrennanConroy reviewed Jul 27, 2021

View reviewed changes

TanayParikh mentioned this pull request Jul 27, 2021

Refactor SignalR Transports Errors #34765

Closed

This was referenced Sep 17, 2021

Revert Enforce WebSockets Transport for Blazor #36655

Closed

Revert Enforce WebSockets Transport for Blazor #36656

Merged

BrennanConroy mentioned this pull request Sep 17, 2021

RC1 Failed connection handshake after update from Preview 7 -> RC1 #36672

Closed

dougbu pushed a commit that referenced this pull request Sep 18, 2021

Revert Enforce WebSockets Transport for Blazor (#36656)

743d9bc

* Revert Enforce WebSockets Transport for Blazor (changes introduced in #34644) * Updated Release JS Files

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Blazor Disable Non-WebSockets Transports by Default #34644

Blazor Disable Non-WebSockets Transports by Default #34644

TanayParikh commented Jul 23, 2021 •

edited

Loading

pranavkm commented Jul 23, 2021

TanayParikh commented Jul 23, 2021

pranavkm Jul 23, 2021

TanayParikh Jul 23, 2021

BrennanConroy Jul 23, 2021

TanayParikh Jul 23, 2021

BrennanConroy Jul 23, 2021

TanayParikh Jul 23, 2021 •

edited

Loading

TanayParikh Jul 23, 2021

BrennanConroy commented Jul 23, 2021 •

edited

Loading

TanayParikh commented Jul 25, 2021

pranavkm Jul 26, 2021

TanayParikh Jul 26, 2021 •

edited

Loading

pranavkm left a comment

TanayParikh commented Jul 26, 2021

pranavkm Jul 26, 2021

BrennanConroy Jul 27, 2021

BrennanConroy Jul 27, 2021

TanayParikh Jul 27, 2021

BrennanConroy Jul 27, 2021

TanayParikh Jul 27, 2021

		{
		options.Transports = Microsoft.AspNetCore.Http.Connections.HttpTransportType.LongPolling;

Blazor Disable Non-WebSockets Transports by Default #34644

Blazor Disable Non-WebSockets Transports by Default #34644

Conversation

TanayParikh commented Jul 23, 2021 • edited Loading

Scenarios

Custom Configuration

Server Side

Client Side

pranavkm commented Jul 23, 2021

TanayParikh commented Jul 23, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TanayParikh Jul 23, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

BrennanConroy commented Jul 23, 2021 • edited Loading

TanayParikh commented Jul 25, 2021

Choose a reason for hiding this comment

TanayParikh Jul 26, 2021 • edited Loading

Choose a reason for hiding this comment

pranavkm left a comment

Choose a reason for hiding this comment

TanayParikh commented Jul 26, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TanayParikh commented Jul 23, 2021 •

edited

Loading

TanayParikh Jul 23, 2021 •

edited

Loading

BrennanConroy commented Jul 23, 2021 •

edited

Loading

TanayParikh Jul 26, 2021 •

edited

Loading