SignalR on IIS 7.5 always uses Long Polling with every Browser

Question

I know SignalR has it's transport-method hierarchy: Websocket->Server-Sent Events->Forever Frame->Long Polling

But when I check the console in every Browser, I noticed that the transport is always Long Polling.

I'm using Windows 7, IIS Express 7.5 and Visual Studio 2013 (SignalR 2.0 of course).

I know Websocket is only supported with IIS 8, but at least SSE or Forever Frame for IE should work.

For example in Google Chrome I get this:

That means, Chrome is trying to use SSE right? But why is it cancelled?

And here a screenshot of Fiddler with Internet explorer:

It's blue... and the code is 200. (and why are there different ports? The site runs under port 4040, but where does 11437 come from?) There isn't even an explanation, why IE doesn't go on using SSE.

I mean, SSE/Forever Frame does work with IIS 7.5, doesn't it?

Thank you in advance!

PS: Before you ask, I am at home and not behind a proxy

Answer 1

Well this is a bit late, but I want to resolve this anyway.

The reason was Bitdefender Internet Security 2013. It buffers requests or something like that, I don't know exactly :X

Anyways, I uninstalled it and that did the trick :D

Answer 2

The SignalR requests to port 11437 are being made by Visual Studio's new Browser Link feature which can be disabled.

Can you show us your server-side code (particularly anything in OnConnected)? It would also be helpful to see the responses to the SSE and ForeverFrame /connect requests.

Lastly, looking at SignalR's server-side tracing could be helpful.