Socket closure when sending twice null binary data from chrome

During some test with Dark Web Socket Terminal (and Chrome) I found out that if I send an empty binary frame twice the client requires a closure.

You can double check this also with your Echo example.

I solved removing compressing bit if payload length is zero.
So in WebSocketFrame internal costructor

internal WebSocketFrame (
  Fin fin, Opcode opcode, PayloadData payloadData, bool compressed, bool mask)
{
  _fin = fin;
  var len = payloadData.Length;
  _rsv1 = opcode.IsData () && compressed && len > 0 ? Rsv.On : Rsv.Off;
  //...

In your opinion, is it correct? Is it a bug of Chrome?

Start in the WebSocketFrame internal constructor shown in the issue and reproduce the problem with Chrome and the Echo example by sending an empty binary frame twice. Inspect how the compression bit is set for a zero-length payload; done means determining whether that behavior explains the closure and verifying the result against the reported reproduction.