SignalR Core: Connection closes with error code 1007

Question

I am writing a simple SignalR Core implementation, in which the user types text into a textarea, which is then displayed to another use. This is done by transmitting the content string through a SignalR hub. This works fine for a couple of minutes, but then the connection suddenly closes with the message:

'Error: Websocket closed with status code: 1007 ()'.

Looking up the error code, it seems that the problem is that the string is not UTF-8 encoded. This doesn't really makes sense to me, since I am sending a normal javascript string to a hub function accepting a string. Surely, this is a textbook example of a simple SignalR implementation?

I've tried encoding the string as UTF-8, by this trick I found:

function forceUnicodeEncoding(string) {
  return unescape(encodeURIComponent(string));
}

But that doesn't fix the issue.

My hub function looks like this:

public async Task SendContent(string text)
{
    _contentString = text;
    await Clients.Others.SendAsync("ReceiveContent", _contentString);
}

_contentString is a static cache of the entered content.

I call it like this

    this.hubConnection.invoke('SendContent', contentString)

Where "contentString" is the value of event.target from the TextArea onChange function.

Am I missing something here?

Edit: This seems like it's connected to using non-standard characters, such as the nordic letters æøå

Steps to reproduce, for people without nordic keyboards

1) Create an input element or a textarea with an onChange handler that submits the entire content to a SignalR hub function that accepts a string, through a websocket connection.

2) Copy-paste the following string into the input element: "æææææææææææææææææææææææææææææææææææææææææææææææææææææææææææææææææææææææææææææææææææææææææææææææææææææææææææææææææææææææ"

3) Type random crap for a few seconds.

The websocket connection should now disconnect with an error code 1007.

The funny thing is that I need a relative large amount of nordic characters to trigger the issue. It's not enough with just a few at the beginning.

Answer 1

https://github.com/dotnet/corefx/issues/29834

This turned out to be an error in the actual websocket implementation. Unfortunately, there is no workaround for now, so I've switched to SSE transport until the error is fixed.