Question

I have a SignalR 2.0 server hosted in IIS7 with a javascript client, targeting mainly Chrome browsers at the moment.

Without cross-domain, the SignalR transport is Server Sent Events, which works very nicely and is efficient.

I added CORS support to the server in the suggested fashion, using Microsoft.Owin.Cors -- that makes the server work with the client cross domain-- however, the SignalR transport is now long-polling; this is going to cause a much higher load on my servers, as the SignalR messages from the server to the client are quite frequent.

I'd really like to get Server-Sent Events and CORS support working together, and from my understanding of the protocols I don't see a reason why it can't be done. Any suggestions? Anyone have any luck in the same scenario with other browsers?

Was it helpful?

Solution

SignalR currently doesn't try to establish cross-domain SSE connections by default.

This decision was made before browsers had CORS compatible EventSource implementations, so it was seen as wasteful to even attempt establishing cross-domain SSE connections.

Starting with SignalR 2.0.3, cross-domain SSE connections will be attempted by default.

In the meantime you can manually specify which transports to try and what order to try them in:

$.connection.hub.start({transport: ["webSockets", "serverSentEvents", "foreverFrame", "longPolling"]});

http://www.asp.net/signalr/overview/signalr-20/hubs-api/hubs-api-guide-javascript-client#transport

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top