No more websockets after upgrading to SignalR 1.1 & .net Core 2.2

[StefanKoenigMUC]

Hi all,

this morning i upgraded my application to SignalR 1.1 (by this i was force to upgrade from .net core 2.1.5 to .net core 2.2).

Since those upgrades, no more Websocket connections are negotiated between my Client (Angular, also using SignalR 1.1 Libs) and my .net core server.

I've honestly no clue whats causing the problem, as there are no significant changes to the application.

Due to the upgrades, some changes to my CORS policy where necessarcy, it looks like this right now:

               services.AddCors(o => o.AddPolicy("MyPolicy", =>
              {

                    builder

                           .SetIsOriginAllowed(isOriginAllowed: _ => true)

                           .WithMethods("GET", "PUT", "POST", "DELETE", "PATCH", "OPTIONS")

                           .AllowCredentials()

                           .AllowAnyHeader();

                           .WithHeaders("Authorization", "Content-Type", "X-Requested-With",);

;                }));

SignalR is configured like this:

services.AddSignalR().AddMessagePackProtocol();

         app.UseSignalR(routes =>

            { // some routes}

Does anyone have an idea regarding my problem?

Thanks in advance!

[StefanKoenigMUC]

but doesn't change behavior at all.

trace looks like that:

2018-12-04T16:25:54.972Z DEBUG [main.js:5278] Debug: Starting HubConnection.
vendor.js:423401 2018-12-04T16:25:54.975Z DEBUG [main.js:5278] Debug: Starting connection with transfer format 'Binary'.
vendor.js:423401 2018-12-04T16:25:54.985Z DEBUG [main.js:5278] Debug: Sending negotiation request: https://localhost:5001/MessageHub/negotiate
vendor.js:423401 2018-12-04T16:25:55.254Z DEBUG [main.js:5278] Debug: Skipping transport 'ServerSentEvents' because it does not support the requested transfer format 'Binary'.
vendor.js:423401 2018-12-04T16:25:55.254Z DEBUG [main.js:5278] Debug: Selecting transport 'LongPolling'

negotiation response looks like that:

{"connectionId":"MnSv28k1a4WnyjkTvaS94Q","availableTransports":[{"transport":"ServerSentEvents","transferFormats":["Text"]},{"transport":"LongPolling","transferFormats":["Text","Binary"]}]}

[BrennanConroy]

That looks like your server doesn't support WebSockets, what is your server environment?

[StefanKoenigMUC]

.net core (upgraded before creating this ticket from 2.1.5 to 2.2), i assume something has changed by this update, but 'ive no idea what.

websockets are enabled like that:

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
       {
           if (env.IsDevelopment())
           {
               app.UseDeveloperExceptionPage();
           }
           else
           {
               app.UseExceptionHandler("/Error");
               //app.UseHsts();
           }
           app.UseCors("MyPolicy");


           app.UseWebSockets();
           app.UseAuthentication();

           app.UseResponseCompression();


           app.UseHttpsRedirection();
           app.UseStaticFiles();
           app.UseCookiePolicy();

           app.UseMvc();


           app.UseSignalR(routes =>
           {
               routes.MapHub<UpdatePortfolioMessageHub>("/MessageHub");
           });
       }

and i'm using version 2.2 of all those Webpack packages available:

  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.App" />
    <PackageReference Include="Microsoft.AspNetCore.SignalR" Version="1.1.0" />
    <PackageReference Include="Microsoft.AspNetCore.SignalR.Client.Core" Version="1.1.0" />
    <PackageReference Include="Microsoft.AspNetCore.SignalR.Common" Version="1.1.0" />
    <PackageReference Include="Microsoft.AspNetCore.SignalR.Core" Version="1.1.0" />
    <PackageReference Include="Microsoft.AspNetCore.SignalR.Protocols.Json" Version="1.1.0" />
    <PackageReference Include="Microsoft.AspNetCore.SignalR.Protocols.MessagePack" Version="1.1.0" />
    <PackageReference Include="Microsoft.AspNetCore.SignalR.Redis" Version="1.1.0" />
    <PackageReference Include="Microsoft.AspNetCore.WebSockets" Version="2.2.0" />
    <PackageReference Include="Microsoft.AspNetCore.WebUtilities" Version="2.2.0" />
  </ItemGroup>

[BrennanConroy]

What OS? Are you hosting behind a proxy? IIS?

[StefanKoenigMUC]

Windows 10, No Proxy, No IIS (using the built in Webserver Kestrel).

But as you mentioned it, i tried to switch to my local IIS and now it's working again. I'll have a deeper look into it.

[StefanKoenigMUC]

Finally i was not able to find the source of the problem, switched finally my dev-env. to IIS and now everything is working as usual again.

[BrennanConroy]

Ok, to summarize, you're on Win 10 hosting with raw kestrel. You switched from 2.1.5 to 2.2 and now your SignalR connection no longer negotiates WebSockets. You then host behind IIS with the same machine/setup and are able to negotiate WebSockets on your SignalR connection?

Could you try something really quickly for me, not using IIS try to connect to the server with skipNegotiation set to true and WebSockets selected as the transport to connect with.

let connection = new signalR.HubConnectionBuilder()
.withUrl("/myhub", {
    skipNegotiation: true,
    transport: signalR.HttpTransportType.WebSockets
})
.build();

[BrennanConroy]

cc @shirhatti

[Tratcher]

This sounds like the HTTP/2 regression we fixed in RTM. Maybe it didn't make it in?

[BrennanConroy]

Nupkg has the change so it's not that.

[StefanKoenigMUC]

oh, sorry i have not seen your reply :-( - is that test still necessary?

[BrennanConroy]

@Cyrill1234 Your app doesn't work because CORS changed between 2.1 and 2.2, you can use AllowAnyOrigin with AllowCredentials see https://docs.microsoft.com/en-us/aspnet/core/migration/21-to-22?view=aspnetcore-2.2&tabs=visual-studio#update-cors-policy

@StefanKoenigMUC Yes that would be helpful, try it without hosting behind IIS. Also, is it possible for you to make a repro app?

[StefanKoenigMUC]

ok, might take until next week, as i'm off work at the moment - maybe i find some time in the evenings.

[Looooooka]

Same problem here. Luckily I came upon this thread and stopped worrying so much.
Debugging straight from net core(commandName: "project") it doesn't work even after adding any possible combination of urls in the WithOrigins command.
Debugging from IIS(commandName: "IIS")...it works as before.

[BrennanConroy]

@Looooooka Are you seeing the issue where WebSockets isn't working when hosting from command line but is working behind IIS?

[BrennanConroy]

@nuteman1 Can you please open a new issue describing the problem you're having. It's definitely not the same issue as OP.

[BrennanConroy]

@StefanKoenigMUC We haven't been able to repro this and haven't heard from you in a while. I'll close this issue tomorrow if there is no response.

[StefanKoenigMUC]

Sorry for not giving feedback for so long. Some troubles within the last months, so that i'm was not able to continue here.

Your workaround changes the error to something else:

2019-02-21T14:01:25.875Z ERROR [main.js:1044] Error: Error parsing handshake response: TypeError: Right-hand side of 'instanceof' is not callable
    at HubConnection.push../node_modules/@aspnet/signalr/dist/esm/HubConnection.js.HubConnection.processHandshakeResponse (HubConnection.js:368)
    at HubConnection.push../node_modules/@aspnet/signalr/dist/esm/HubConnection.js.HubConnection.processIncomingData (HubConnection.js:318)
    at WebSocketTransport.HubConnection.connection.onreceive (HubConnection.js:65)
    at WebSocket.webSocket.onmessage [as __zone_symbol__ON_PROPERTYmessage] (WebSocketTransport.js:107)
    at WebSocket.wrapFn (zone.js:1332)
    at ZoneDelegate.push../node_modules/zone.js/dist/zone.js.ZoneDelegate.invokeTask (zone.js:423)
    at Object.onInvokeTask (core.js:17280)
    at ZoneDelegate.push../node_modules/zone.js/dist/zone.js.ZoneDelegate.invokeTask (zone.js:422)
    at Zone.push../node_modules/zone.js/dist/zone.js.Zone.runTask (zone.js:195)
    at ZoneTask.push../node_modules/zone.js/dist/zone.js.ZoneTask.invokeTask [as invoke] (zone.js:498).

Currently used versions are:

    "@aspnet/signalr": "^1.1.2",
    "@aspnet/signalr-protocol-msgpack": "^1.1.0",

using Windows 2016 with IIS 10. As there should now be more time, i will prepare an example during the next days.

Edit:

logs with trace:

2019-02-21T14:24:27.554Z DEBUG [main.js:5264] Debug: Starting HubConnection.
ngx-logger.js:251 2019-02-21T14:24:27.558Z DEBUG [main.js:5264] Debug: Starting connection with transfer format 'Text'.
ngx-logger.js:251 2019-02-21T14:24:27.560Z DEBUG [main.js:5264] Trace: (WebSockets transport) Connecting.
zone.js:1755 [Violation] 'load' handler took 183ms
ngx-logger.js:251 2019-02-21T14:24:27.801Z DEBUG [main.js:5260] Information: WebSocket connected to wss://localhost:4200/UpdateFundMessageHub?access_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ0ZXN0VXNlcjEiLCJ1bmlxdWVfbmFtZSI6InRlc3RVc2VyMSIsImp0aSI6IjUyYjdiNDBlLWU3ZjctNDY5ZS05ZTU4LTE1ZTI3NzA1ZmQ2OSIsImlhdCI6MTU1MDc1ODk1MywiaXAiOiI4MC4xOTAuMTUxLjY2Iiwicm9sIjoiYXBpX2FjY2VzcyIsImlkIjoiMSIsImh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3dzLzIwMDUvMDUvaWRlbnRpdHkvY2xhaW1zL25hbWUiOiJ0ZXN0VXNlcjEiLCJuYmYiOjE1NTA3NTg4NDQsImV4cCI6MTU1MDc1OTU1MiwiaXNzIjoieW91cmRvbWFpbi5jb20iLCJhdWQiOiJ5b3VyZG9tYWluLmNvbSJ9.-i6Nk8PjFFqU9LKKTtNX6wtO74ItJ1GfusugkciJEkY.
ngx-logger.js:251 2019-02-21T14:24:27.802Z DEBUG [main.js:5264] Debug: Sending handshake request.
ngx-logger.js:251 2019-02-21T14:24:27.803Z DEBUG [main.js:5264] Trace: (WebSockets transport) sending data. String data of length 32.
ngx-logger.js:251 2019-02-21T14:24:27.804Z DEBUG [main.js:5260] Information: Using HubProtocol 'json'.
ngx-logger.js:251 2019-02-21T14:24:27.946Z DEBUG [main.js:5264] Trace: (WebSockets transport) data received. String data of length 3.
ngx-logger.js:245 2019-02-21T14:24:27.947Z ERROR [main.js:5254] SIGNALR: Error parsing handshake response: TypeError: Right-hand side of 'instanceof' is not callable

data objects seems empty

data = "{}"

[BrennanConroy]

What kind of environment are you running the client in?

It looks like either data instanceof ArrayBuffer or data instanceof Buffer is failing, what do those types look like in your environment?

[IVL-Mukesh]

We are also experiencing same issue that mentioned by @StefanKoenigMUC in last comment . Please help us...Thanks

[jtbrower]

Regarding the "Error parsing handshake response: TypeError: Right-hand side of 'instanceof' is not callable" error I thought I would share with everyone what was causing this error for me, though I realize that some details of my problem are different.

I am serving up both MessagePack and JSON capable endpoints using NetCore 3.Preview+ (debugged through Visual Studio 2019 Preview) while my Angular 7 client SPA is using signalR 1.1.2 / signalr-protocol-msgpack 1.1.0 via Chrome 72.0.3626.121.

When I first enabled MessagePack on the client I had to introduce a work-around that @BrennanConroy and @andreatosato provided for issue aspnet/SignalR#2736 where a script block was added to the index.html and polyfills.ts files of Angular. Although that work-around solved my MessagePack error, I found that if I switch the client back to use JSON instead of MessagePack I had to remove the script block from index.html or the "Right-hand side of 'instanceof' is not callable" exception would be thrown.

To summarize, the following script block in index.html will cause the error when using JSON but is required when using MessagePack. The pollyfill.ts modification can remain for both MessagePack and JSON enabled clients.

var global = global || window;
var Buffer = Buffer || [];
var process = process || {
  env: { DEBUG: undefined },
  version: []
};

[StefanKoenigMUC]

i finally figured it out, that error occurs for me: error occured only, when MessagePack is just installed on ServerSide of the application.
Adding it to the client, makes it work again.

[analogrelay]

Yeah, the MessagePack library brings along polyfills for ArrayBuffer and Buffer. It sounds like we can make a small improvement here by checking for the existance of these types before running instanceof . We do this in the messagepack library but not in the main library

https:/aspnet/AspNetCore/blob/321327f84b2b22dcff2e9beb06a9a64236c5cced/src/SignalR/clients/ts/signalr-protocol-msgpack/src/Utils.ts#L6-L11

We'll look improving the error messaging for this in a future release

[analogrelay]

var Buffer = Buffer || [];

It looks like this polyfill is what causes the problem. We check Buffer against undefined but if the polyfill is triggered, Buffer is set to [] which means typeof Buffer returns object. That means we get past the typeof Buffer check and then try to use it with instanceof, which fails.

I think we need a new approach to this one. Is someone able to provide a clonable sample that reproduces the problem?

A longer term plan may be to consider a new MessagePack library that doesn't depend on Buffer at all, such as https:/msgpack/msgpack-javascript

[analogrelay]

Closing as this appears to be an issue with the polyfill that was provided in a comment above. If we can get more context on this polyfill as requested above we can see if there's something we can do to fix it.