This is a blatant bug. We special case websockets when creating the URL and we shouldn't.
Modified the ping server to no longer special case websockets and to …
…use the connection.url.
- Also added a test to verify the fix.
tested on websockets, pingServer is invoked periodically sending a request to "/signalr/ping?connectionData=%5B%7B%22name%22%3A%22hubconnectionapi%22%7D%5D".
Response is "pong" and the deferral is completed.
I can still repro with version 2.0.0 downloaded through nuget - https://github.com/tonyeung/signalr
Is there a new version published already somewhere since the bug is listed as closed and done?
Try with a nightly build from https://www.myget.org/F/aspnetwebstacknightly/
Thanks, I went ahead and just replaced the offending line with this - url = connection.url + "/ping";
Hi there - I'm still seeing this also with nuget 2.0.0 in a websocket & x-domain environment, and using a websocket port of 6757. The ping ajax() is called with just the relative URL, which in the console causes a request to http://server/signalr/ping..., which 404s (presumably port 80).
Similarly to tonyeung above, if I hack signalr JS and replace
baseUrl = connection.transport.name === "webSockets" ? "" : connection.baseUrl;
baseUrl = // connection.transport.name === "webSockets" ? "" :
...all is well.
It's been fixed but there's no official version with the fix. Are you using nightlies? If not then you do not have the fix and what you're describing is expected.
Thanks David. Makes sense so.
Great work, by the way. Still amazed at the simplicity and ease-of-use of SignalR.
Re-worked how long polling transport starts. Also added a common serv…
…er ping method that any transport can use.