Websocket response code: 204 (IIS8) - websocket

Question

I have a .NET Core 2.0 application running with the preview SignalR. I'm running on Windows Server 2012 R2 behind IIS 8.5.
Websockets are enabled in the server roles, and are also configured in IIS.
When I attempt to initiate a SignalR connection over Websocket, I get this response:
Error during WebSocket handshake: Unexpected response code: 204
Everything I've read says that this should work, and as far as I can tell I have all of the configurations set up correctly. Can anyone guide me on debugging this issue?
MORE DETAILS -------
My application has two extension methods for adding SignalR to the application and to the services:
/// <summary>
/// .NET Core 2.0-specific extensions for Signal-R.
/// </summary>
public static class SignalRExtensions
{
/// <summary>
/// Use Signal-R and set up the base hub in the application.
/// </summary>
/// <param name="app">The Builder for the .NET Core 2.0 application.</param>
/// <param name="serviceProvider">The application's service provider.</param>
/// <returns>A reference to the application builder object.</returns>
public static IApplicationBuilder UseSignalR_NETCORE20(this IApplicationBuilder app, IServiceProvider serviceProvider)
{
app.UseSignalR(routes =>
{
routes.MapHub<BaseHub>("baseHub");
});
SignalRHelper.BaseHubContext = serviceProvider.GetService<IHubContext<BaseHub>>();
return app;
}
/// <summary>
/// Add Signal-R servies to a .NET Core 20 application.
/// </summary>
/// <param name="services">The service collection.</param>
/// <returns>The Signal-R builder object.</returns>
public static ISignalRBuilder AddSignalR_NETCORE20(this IServiceCollection services)
{
var settings = new JsonSerializerSettings();
settings.ContractResolver = new SignalRContractResolver();
var serializer = JsonSerializer.Create(settings);
services.Add(new ServiceDescriptor(typeof(JsonSerializer), provider => serializer, ServiceLifetime.Transient));
services.AddSingleton<IMessageSender, MessageSender>();
services.AddSingleton<IContractResolver, SignalRContractResolver>();
return services.AddSignalR();
}
}
It has code to use web Sockets if we're running on Windows Server 2012 R2 or higher (I needed this code in .NET Core 1.1, I might not need the check in 2.0 but haven't verified yet):
// Don't enable web sockets if we're running on a Windows version lower than 6.2 (Windows 8/Windows Server 2012 R2)
Regex windowsRex = new Regex(#"Microsoft Windows ([0-9]*\.[0-9*]).*");
Match match = windowsRex.Match(RuntimeInformation.OSDescription);
if (!match.Success || double.Parse(match.Groups[1].Value) > 6.1)
{
app.UseWebSockets();
}
The client connection code looks something like this (sanitized a bit):
Publisher.signalRHubURL = /* set URL */
Publisher.options = { logging: false };
Publisher.signalRHub = new signalR.HubConnection(Publisher.signalRHubURL, Publisher.options);
Publisher.showConnectionStatus('disconnected', 'Disconnected. Real-Time updates offline.');
Publisher.signalRHub.start().then(function() {
Publisher.isInitialized = true;
Publisher.signalRHub.on("updateSubscribedDisplay", function(jsonData) {
Publisher.startMessageQueueThread(jsonData);
});
Publisher.signalRHub.onclose(Publisher.reconnect);
if (Publisher.subscriberQueue.length > 0) {
/* send some data to the server */
}
Publisher.showConnectionStatus('connected', 'Data connection is normal.');
}).catch(function(error) {
// WebSockets not supported, fall back to LongPolling
Publisher.logError(error, 1);
Publisher.options.transport = signalR.TransportType.LongPolling;
Publisher.signalRHub = new signalR.HubConnection(Publisher.signalRHubURL, Publisher.options);
Publisher.signalRHub.start().then(function() {
Publisher.isInitialized = true;
Publisher.signalRHub.on("updateSubscribedDisplay", function(jsonData) {
Publisher.startMessageQueueThread(jsonData);
});
Publisher.signalRHub.onclose(Publisher.reconnect);
if (Publisher.subscriberQueue.length > 0) {
/* send some data to the server */
}
Publisher.showConnectionStatus('connected', 'Data connection is normal.');
});
});
I am using full IIS, and webSockets are enabled:
In the network tab, I see the webSocket request fail and then the longPolling request take over:
I notice that once the connection is made, signalR is reporting WebSockets as an available transport:
MORE DETAILS -------
I added this at the very top of my Startup class's Configure method:
app.Use(async (context, next) =>
{
ServerFactory.GetLogManager().Log(string.Format("Request Scheme: {0}", context.Request.Scheme));
await next();
});
This is always logging "http" as the scheme (I expect at least one "ws" for the webSocket request). Is this a valid test? Does it indicate that IIS is somehow mangling the webSocket request before passing it off to Kestrel?
Maybe related to ANCM Issue 163 (https://github.com/aspnet/AspNetCoreModule/issues/163)?
I do have this rewrite rule in my web.config: