Running Kestrel through IIS Express doesn't support Server Sent Events

[Tragetaschen]

I've got my ASP.NET 5 project and use SignalR 2.2 through the Owin middleware adaption. When I run Kestrel on the command line stand-alone, Firefox is using the Server Sent Events transport. However, when I CTRL+F5 in VS using the IIS Express setting, the /connect request in Firefox doesn't finish and SignalR falls back to long polling, after a timeout of 5 seconds. The latter is quite annoying during development.

I've found an older issue in SignalR/SignalR#625, where @davidfowl identified the issue being a proxy sitting between the server and the browser, but I don't know if IIS qualifies as such here.

[davidfowl]

This isn't a tooling issue. The HttpPlatformHandler buffers aspnet/IISIntegration#7 (comment). It's a known issue but unlikely to be fixed in the short term.

[Tragetaschen]

Very annoying. That probably means, hosting in Azure is affected as well.

Forever Frame doesn't work either (now I can say: as expected) and falls back to Long Polling as well.

Is there an out-of-the-box way to teach SignalR to /negotiate only Long Polling when running behind a proxy (like checking for the X-Forwarded-For header) to avoid the 5 second delay? On my embedded platform, I'm exposing Kestrel directly so I don't want to lose the ServerSentEvents there by instructing the client to only try Long Polling.

[davidfowl]

Very annoying. That probably means, hosting in Azure is affected as well.

Agreed. We'll see how far we can get removing buffering from the platform handler. It's just not the pri 0 thing at the moment (esp since SignalR 3.0 isn't aligned with the 1.0 release).

Forever Frame doesn't work either (now I can say: as expected) and falls back to Long Polling as well.

Yep, it has the same problem.

Is there an out-of-the-box way to teach SignalR to /negotiate only Long Polling when running behind a proxy (like checking for the X-Forwarded-For header) to avoid the 5 second delay? On my embedded platform, I'm exposing Kestrel directly so I don't want to lose the ServerSentEvents there by instructing the client to only try Long Polling.

Nope, you could probably write some middleware to change the querystring to specify the transport based on that header value though.

[Tragetaschen]

I've opted for the sledge hammer in Startup.Configure:

if (!isOnInstrument)
{
    var transportManager = dependencyResolver.Resolve<ITransportManager>() as TransportManager;
    transportManager.Remove("foreverFrame");
    transportManager.Remove("serverSentEvents");
    transportManager.Remove("webSockets");
}

The initial /connect now results in a 400 Bad Request, and recovers quickly to Long Polling, which is ok for those secondary hosting options in my environment.

Thanks!

[davidfowl]

FWIW, we made this nicer in SignalR v3 (disabling transports). Though to think of it, we might want to allow it on a per connection level.