Home/ Questions/Q 8704237
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-13T03:03:12+00:00

I’m using the latest SignalR from NuGet in a MVC4 site. Using the sample

  • 0

I’m using the latest SignalR from NuGet in a MVC4 site. Using the sample hub code (or any code), I’m getting some weird connection problems. Everything loads fine, SignalR makes the negotiate call and logs “EventSource Connected” and returns connectionid. The problem starts when it makes the signalR/connect request with any transport. It returns a 200 response with the proper headers but the connection hangs open. If the called hub method executes a method on Caller or Clients, it does not get executed in the browser until the next request OR after 10-30 seconds later if you sit and wait. It’s like something’s stuck in the pipe and it gets flushed by the next request or some cleanup mechanism.

I made a clean project for this in a new website with its own app pool. The issue occurs only on one machine and only under IIS7.5. The same project run on the same machine under IIS Express or Cassini works fine. This project ran fine the last time I worked on it about a month ago. I’ve tried different browsers and different jQuery versions. I’ve tried restarting the entire machine and spent several hours in fiddler/debugger to no avail.

This is the server-side code the test runs:

public class Chub : Hub {
    public void CallMeBack() {
        Caller.callme();
    }
}

Blew the whole day on this, hope someone can help!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Compression doesn’t play well with streaming responses like EventSource, ForeverFrame, etc. as used by SignalR, so switching off compression is the only solution right now.

    Maybe it’s possible to switch off compression just for the ~/signalr path, I’ll try that later on and update this answer with the results.

    UPDATE: After a thorough analysis, I’ve found out this issue only occurs when the application pool is set to “Classic Mode” in IIS and Dynamic Compression is enabled. See my comment on this SignalR issue. If you use an “Integrated Mode” application pool, you are not affected and SignalR works as expected (even if compression is enabled).

    In case you’re stuck with Classic Mode + Dynamic Compression, add the following to your web.config for switching off compression only for the /signalr path:

    <location path="signalr">
  <system.webServer>
    <urlCompression doDynamicCompression="false"/>
  </system.webServer>
</location>
    • 0