Brennan
Brennan
--- **Issue moved from dotnet/aspnetcore#26600** - Please respond to @mithunscout. --- _From @mithunscout on Tuesday, October 6, 2020 8:49:06 AM_ Hi Brennan Pls find attached the Server Logs for the...
If you got a successful handshake response that very likely means the protocol is supported. It's very likely that you implemented something wrong after the handshake that's causing issues. >...
You can't set headers on WebSocket requests in the browser. This is a limitation of the browser and not something SignalR can fix. See https://github.com/whatwg/websockets/issues/16 if you're passionate about browsers...
Ungraceful disconnects can take a long time to be detected by TCP, take a look at https://stackoverflow.com/questions/13085676/tcp-socket-no-connection-timeout for some info related to that. Because of this, the SignalR protocol sends...
Well the regression is it now throws "Invalid URL" when it didn't throw before. But fair point.
I have now seen this 3 or 4 times in PR's/product code. What would it take to get some movement on warning about this?
Ah perfect, thanks, I'll follow that thread.
Triage: We have a pattern where we allow configuration of the behavior similar to this. We might need to apply the same pattern here.
That's expected, the messageID is used by the client to tell the server which message it received last. So if you change the messageID to an older ID then you'll...
> is there any possibility to overcome this issue? What issue? You aren't leaking any data because the data has already been sent to this client before.