Self hosted cross site connection issue with SignalR and Mono and Owin

Question

I'm about ready to pull my hair out over this problem because all the guides show the same one or two solutions, which seem to be working for everyone but myself.

I'm using SignalR in a Mono application, using Owin. I've set EnableCrossDomain = true in my HubConfiguration. I've set up a simple test page using javascript to connect. The negotiate and ping urls are loading without issue and seem to be replying correctly. However I get a cross domain error on the connect call.

It's definitely using my EnableCrossDomain setting because if I set that to false, negotiate doesn't work.

Here's my Javascript to connect (and yes I'm including the /signalr/hubs script which returns the appropriate javascript):

$.connection.hub.url = 'http://localhost:7001/signalr';
$.connection.hub.logging = true;
$.connection.hub.start()
    .done(function () { alert("Now connected!"); })
    .fail(function () { alert("Could not Connect!"); });

Also I've tried jQuery.support.cors = true; as well but it doesn't make any difference.

I also tried connecting to a regular PersistantConnection like so, with the same problem, so it doesn't appear to be directly related to hubs:

var connection = $.connection('/raw');
connection.url = 'http://localhost:7001/signalr';
connection.start()
    .done(function () { alert("Now connected!"); })
    .fail(function () { alert("Could not Connect!"); });

What am I doing wrong here? Why do ping and negotiate work but not connect?

---

EDIT: Also to make matters weirder, I added some logging and verified that the SignalR CallHandler class is adding the Access-Control-Allow-Origin header for all requests, including the connect request. So it should be working.

---

EDIT 2: So actually thanks to curl it looks like the server is returning a 500 response code, and since it's not also including the header (this must be happening after the code block I added the logging to), Chrome complains about cross site, when really there's probably an exception being thrown somewhere in the server. Hopefully I'll have this figured out shortly and will post an answer here.

Answer 1

So it actually turned out to have nothing to do with cross site access, and everything to do with Mono incompatibilities.

After I enabled exception logging for SignalR (https://stackoverflow.com/a/16577890/299262) I got the following exception instead of just a blank http 500 error:

System.InvalidOperationException: The connection id is in the incorrect format.
  at Microsoft.AspNet.SignalR.PersistentConnection.GetConnectionId (Microsoft.AspNet.SignalR.Hosting.HostContext context, System.String connectionToken) [0x00000] in <filename unknown>:0 
  at Microsoft.AspNet.SignalR.PersistentConnection.ProcessRequest (Microsoft.AspNet.SignalR.Hosting.HostContext context) [0x00000] in <filename unknown>:0 
  at Microsoft.AspNet.SignalR.Hubs.HubDispatcher.ProcessRequest (Microsoft.AspNet.SignalR.Hosting.HostContext context) [0x00000] in <filename unknown>:0 
  at Microsoft.AspNet.SignalR.Owin.CallHandler.Invoke (IDictionary`2 environment) [0x00000] in <filename unknown>:0 
  at Microsoft.AspNet.SignalR.Owin.Handlers.HubDispatcherHandler.Invoke (IDictionary`2 environment) [0x00000] in <filename unknown>:0 
  at Microsoft.AspNet.SignalR.Owin.Handlers.PersistentConnectionHandler.Invoke (IDictionary`2 environment) [0x00000] in <filename unknown>:0 
  at Microsoft.Owin.Diagnostics.ShowExceptionsMiddleware.Invoke (IDictionary`2 environment) [0x00000] in <filename unknown>

That led me to find this ticket on the SignalR repo issues list: https://github.com/SignalR/SignalR/issues/1914

So in the end, the fix was to comment out the following line in HostDependencyResolverExtensions.cs:

resolver.InitializePerformanceCounters(instanceName, hostShutdownToken);