Switching WebSocket to Long Polling fallback in a Blazor App

Then SignalR switches connection to another protocol to maintain transport working and your application published.

This is magic. How does SignalR resolves this? SignalR is an open source Library developed by Microsoft to allow real time communication between applications and servers, using different transport protocols and technologies like Websockets, Server-Sent Events (SSE) and LongPolling. Using C# code, developers can get full capability to switch between protocols to maintain connection alive. SignalR is an API that calls Java Script functions on clients from the server with remote procedures calls (RPC) in a persistent connection instead of a classic HTTP model with request – response communication.

The following image shows an example when Nginx conguration for a Blazor App has an error in the headers, and the console of developer tools window drops an error message sent by the blazor.web.js. In this case, a connection to a web socket can’t be established and SignalR switches to a Long Polling protocol:

This is a common mistake that developers found with web browsers developer tools. In this case, SignalR resolves the switching automatically and the App still works. A real time communication push data to get updates from the back end. 

How does SignalR makes this magic?

Let’s take a look at the configuration file on an nginx reverse proxy server:

      http {
        map $http_connection $connection_upgrade {
          "~*Upgrade" $http_connection;
          default keep-alive;
        }
      
        server {
          listen 80;
          server_name example.com *.example.com
      
          # Configure the SignalR Endpoint
          location / {
            # App server url
            proxy_pass http://localhost:5000;
      
            # Configuration for WebSockets
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
            proxy_cache off;
      
            # WebSockets were implemented after http/1.0
            proxy_http_version 1.1;
      
           # Configuration for ServerSentEvents
            proxy_buffering off; 
      
            # Configuration for LongPolling or if your KeepAliveInterval is longer than 60 seconds
            proxy_read_timeout 100s;
            proxy_set_header Host $host;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
          }
        }
      }

There are three sections to manage the switching between those transport technologies, marked with ‘#’ comment symbol. This are the configurations to define the HTTP headers in request and responses as they pass to the Localhost server.

What’s the difference between technologies?

According to Microsoft, webSockets is the primary transport technology recommended due to lower latency, reliability and security. If a WebSocket connection is not available, then uses Long Polling instead to transportas you can see from the image above.

How to solve the error?

In this particular case, the error in connect to a WebSocket trough the identifier, was reported by the script blazor.web.js due to bad configuration for PROXY SET HEADER CONNECTION, defines as keep-alive instead of $connection_upgrade. Once the change was made, SignalR connect to WebSocket successfully.

Conclusion

No matter what transport protocol is used in a Blazor App, SignalR ensures that your App will be up and running anyway. You don’t have to warry for details, the SignalR API will take care. Enjoy!