1

I am using SignalR-1.0.0-rc2. I am using cross domain SignalR because some browsers on mobile devices still only allow two connections per domain. So I have one domain for SignalR and one for the web. Server-side, they are both the same.

My implementation works for Opera, Firefox, Chrome, Safari, and IE10. It does not work for IE9, IE8 and IE7. 

jQuery.support.cors = true;
var connection = $.connection.globalHub;
$.connection.hub.url = SignalRDomain;
$.connection.hub.logging = true;
$.connection.hub.qs = "UserID="+UserID+"&Login="+UserLogin+"&UserHash="+UserHash;

connection.client.MyLocalFunction = function () {
    // do something
}

$.connection.hub.start();

I have logging turned on. The IE9/8/7 consoles show me two SignalR trace messages: [13:54:37 UTC+0100] SignalR: Auto detected cross domain url. [13:54:37 UTC+0100] SignalR: Negotiating with 'http://live.mydomain.de/signalr/negotiate'.

If I look in the "Network"-tab of the debugger I don't see that any call to the server is made. So it seems that SignalR just dies after that debug message.

Any ideas?

user197508
  • 1,282
  • 2
  • 18
  • 31
Sparhawk
  • 1,517
  • 1
  • 14
  • 28
  • 1
    Put a break point in the success and error handlers of the negotiate request in the jquery.signalr.1.0.0-rc2.js file, which one is called and what's the value? – N. Taylor Mullen Feb 24 '13 at 20:13
  • @N.TaylorMullen : I checked again with IE10 and IE9. With IE it goes to the success branch, with IE9 to the error branch. Message is "Zugriff verweigert" (Access denied). The eror is thrown in line 7428 of jQuery-1.6.4. That's the line: transport.send( requestHeaders, done ); Any idea? – Sparhawk Feb 24 '13 at 21:26
  • 1
    I'm assuming for IE10 it's using WebSockets transport and for IE9 it's using LongPolling correct? – N. Taylor Mullen Feb 25 '13 at 00:24
  • 1
    The first thing you should do is update to 1.0.0. It sounds like forever frame is failing. Can you file a bug with a repro projects and repro steps? As a workaround you can try forcing longpolling on those older browers and see if it makes a difference. – davidfowl Feb 25 '13 at 03:26
  • @N.TaylorMullen No, IE10 is using long polling since my server is still .NET 4.0 and does not support Websockets yet. IE9 is using nothing, it fails:) – Sparhawk Feb 25 '13 at 21:39
  • @dfowler I forced longpolling now: $.connection.hub.start({ transport: 'longPolling' }) Cant's say that I see any difference in the debug outbut. Upgrade to 1.0.0 is not yet done. – Sparhawk Feb 25 '13 at 21:40
  • @dfowler I now upgraded to 1.0.0. Can't see any difference. Same behaviour. – Sparhawk Feb 25 '13 at 21:51
  • @dfowler: I created a repro project. You can download it here: http://www.yucata.de/bug/recreate_ie_behaviour.zip In IE7,8,9, with the debugger, I don't see any request being sent out. It just fails. – Sparhawk Feb 28 '13 at 21:07
  • @N.TaylorMullen Can you recreate the issue with the solution I provided above? Any solution idea? 50 reputation to be gained :) – Sparhawk Mar 01 '13 at 15:53
  • File a bug, stackoverflow is no place for bug reports. – davidfowl Mar 01 '13 at 19:07
  • @dfowler done: https://github.com/SignalR/SignalR/issues/1619 – Sparhawk Mar 01 '13 at 19:27

1 Answers1

3

So here's the reason why the request is failing: IE9 jQuery AJAX with CORS returns "Access is denied"

You can fix this issue by removing the line "jQuery.support.cors = true".

For SignalR 1.0.0-rc2 it will just work, however for all versions of SignalR 1.0.0 and above you will need to enable cross domain in your map hubs call: SignalR cross domain not working on browsers other than IE10

Community
  • 1
  • 1
N. Taylor Mullen
  • 18,061
  • 6
  • 49
  • 72
  • Bounty well deserved, it solved my issue. I can do some script magic to set jsonp only when I want to. – Sparhawk Mar 01 '13 at 21:32
  • But what still surprises me: Has nobody so far tested cross-domain SignalR in IE9? To make sure that you site remains responsive it seems to be a best practise to put your signalR host in a different subdomain than the rest of your site... – Sparhawk Mar 01 '13 at 21:39
  • That definitely confuses me too, the issue deserves some more investigation. Also something that could have proved troubling is the fact that it still works fine if running in localhost. So even if you have your client at localhost:1111 and server at localhost:2222 it will not replicate the issue. I was only able to by hosting the server via app harbor – N. Taylor Mullen Mar 02 '13 at 00:01
  • 1
    Just updated this answer with the correct/more appropriate fix. – N. Taylor Mullen Mar 15 '13 at 22:45