-
Notifications
You must be signed in to change notification settings - Fork 10.3k
Server Side Blazor support fallback to other protocols #6920
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Does this mean that if your IIS Server or browser doesn't support WebSockets then Razor Components won't work?? Also I remember (almost sure) that it worked fine in previous versions using longpolling, did this break in the latest preview 3? Thank you |
@anurse doesn't SignalR connection automatically handle this? |
They might be hitting other problems #8384 |
Yes, SignalR should be doing this automatically. If we fail to connect to the WebSocket endpoint from the client it should automatically fall back through the other transports. I don't know how/if Razor Components has configured SignalR to know for sure if something is interfering with that. It's also possible it is falling back and some other issue is occurring (as @BrennanConroy) referenced. Getting more logs from the client might help show us what is happening (i.e. if SignalR is trying to fallback or if something is going wrong in that logic). We just posted a new article on Logging and diagnostics in SignalR with information on how to collect more detailed logs that may help identify issues (again, this applies to SignalR, not sure how these config options can be flowed through to Razor Components since they create the HubConnectionBuilder. @mkArtakMSFT it might help to have a doc describing how to collect this kind of diagnostic information in Razor Components (possibly referencing the SignalR one I linked and just expanding on the Razor Components stuff) since these issues can be quite common and generally require a little more logging/diagnostic information to diagnose. |
Actually my issue is quite old (Jan 22) and it might be that other previews worked with fallback, didnt have time to check. This morning i took some time to check. IIS with websockets working as expected. if i uninstall websocket protocol from IIS the UI is not even shown in the browser . Looking at the network tab you can see it does negotiate protocols {connectionId: "GRne4_Dm5hYP4eMBpo0j7w",…} But it doesnt work. Last autumn I was eager to see how it worked and i had to install Telerik Fiddler to understand what a "websockets tunnel" is. So if it uses websockets tunnel it'd work only with websockets i thought. Having some experience in deploying signalr apps in enterprise scenarios i know websockets can be impossibile to obtain (not that they dont install it on IIS, problems are from proxies, firewalls and so on, i am no networking expert but network folks arent good listeners, lets put it like that :) ) Edit: and loving this C# in the browser thing i submitted this issue, at that time there were rumors on fallback i was told by a MVP on twitter. Edit 2: pardon me, Using VS20129RC with .NET 3.0.100-preview3-010431 on Windows 10 1809 17763.379, Chrome 72.0.3626.121 64bit |
Thanks @anurse. We plan to address exposing SignalR hub configuration as part of #8277 Seems like without a way to configure those options we won't be able to move forward here. So marking this investigation as blocked until we figure out how we expose the configuration options for the Hub. @rynowak if you have any suggestion here which can unblock this investigation earlier, please share. |
One note is that the issue you linked is for configuring hub options on the server. In this case you'd need to provide a way to configure the JavaScript client connection options to produce more logging. |
Not as yet. Although we could cover it as part of - #6887 |
This should be fixed now by #8679. |
It would be very nice to have Server Side Blazor implement fallback to other SignalR protocols (SSE, lp...) when a websockets connection cannot be established.
This is actually almost always the case when deploying in Enterprise environment, websockets connection are very seldom established because of the proxies and firewalls implemented.
The text was updated successfully, but these errors were encountered: