This is not a regression and not a blocker I think. It can be reproduced on old qemu version qemu-kvm-rhev-2.9.0-16.el7_4.3.x86_64

(In reply to Guo, Zhiyi from comment #0)
> Description of problem:
> Websocket should be true when using connect qemu with vnc websocket client
> 
> Version-Release number of selected component (if applicable):
> qemu-kvm-4.1.0-5.module+el8.1.0+4076+b5e41ebc.x86_64
> 
> How reproducible:
> 100%
> 
> Steps to Reproduce:
> 1.start qeumu with cli:
> # /usr/libexec/qemu-kvm -vnc 0.0.0.0:66,websocket=5766 -qmp
> tcp:0.0.0.0:8888,server,nowait
> 2.launch a qmp connection:
> # telnet 0.0.0.0 8888
> Trying 0.0.0.0...
> Connected to 0.0.0.0.
> Escape character is '^]'.
> {"QMP": {"version": {"qemu": {"micro": 0, "minor": 1, "major": 4},
> "package": "qemu-kvm-4.1.0-5.module+el8.1.0+4076+b5e41ebc"}, "capabilities":
> ["oob"]}}
> { "execute": "qmp_capabilities" }
> {"return": {}}
> 3.Connect vnc websocket client(onVNC) to qemu
> 4.query vnc status from qmp:
> { "execute": "query-vnc" }
> 
> 
> Actual results:
> After step 3, qmp event generated:
> {"timestamp": {"seconds": 1567488791, "microseconds": 769737}, "event":
> "VNC_CONNECTED", "data": {"server": {"auth": "none", "family": "ipv4",
> "service": "5966", "host": "0.0.0.0", "websocket": false}, "client":
> {"family": "ipv4", "service": "54279", "host": "10.66.8.137", "websocket":
> false}}}
> {"timestamp": {"seconds": 1567488791, "microseconds": 778450}, "event":
> "VNC_INITIALIZED", "data": {"server": {"auth": "none", "family": "ipv4",
> "service": "5966", "host": "0.0.0.0", "websocket": false}, "client":
> {"family": "ipv4", "service": "54279", "host": "10.66.8.137", "websocket":
> false}}}
> 
> It prompts websocket is not enabled and vnc client is not using websocket
> 
> After step 4, vnc status:
> {"return": {"enabled": true, "auth": "none", "family": "ipv4", "clients":
> [{"family": "ipv4", "service": "54279", "host": "10.66.8.137", "websocket":
> true}], "service": "5966", "host": "0.0.0.0"}}
> 
> It prompts vnc client is a websocket client
> 
> Expected results:
> Websocket should be true in qmp event 

I couldn't find out if this problem is exposed via libvirt, but hopefully it's a low-hanging fruit, simple to fix.

(if it's not exposed through libvirt and is not trivial to fix, then consider it a candidate for WONTFIX).

(In reply to Ademar Reis from comment #3)
> (In reply to Guo, Zhiyi from comment #0)
> 
> I couldn't find out if this problem is exposed via libvirt, but hopefully
> it's a low-hanging fruit, simple to fix.
> 
> (if it's not exposed through libvirt and is not trivial to fix, then
> consider it a candidate for WONTFIX).

FYI, this issue is very easy to be observed from libvirt side by listening to the events:
# virsh qemu-monitor-event bochs-uefi --pretty --loop

event VNC_CONNECTED at 1567561972.454853 for domain bochs-uefi: {
  "server": {
    "auth": "none",
    "family": "ipv4",
    "service": "5900",
    "host": "0.0.0.0",
    "websocket": false
  },
  "client": {
    "family": "ipv4",
    "service": "64831",
    "host": "10.66.8.137",
    "websocket": false
  }
}

event VNC_INITIALIZED at 1567561972.477009 for domain bochs-uefi: {
  "server": {
    "auth": "none",
    "family": "ipv4",
    "service": "5900",
    "host": "0.0.0.0",
    "websocket": false
  },
  "client": {
    "family": "ipv4",
    "service": "64831",
    "host": "10.66.8.137",
    "websocket": false
  }
}

> I couldn't find out if this problem is exposed via libvirt, but hopefully
> it's a low-hanging fruit, simple to fix.

Looks like it is indeed ...

--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -278,6 +278,7 @@ static void vnc_client_cache_addr(VncState *client)
     vnc_init_basic_info_from_remote_addr(client->sioc,
                                          qapi_VncClientInfo_base(client->info),
                                          &err);
+    client->info->websocket = client->websocket;
     if (err) {
         qapi_free_VncClientInfo(client->info);
         client->info = NULL;

https://patchwork.ozlabs.org/patch/1157470/

QEMU has been recently split into sub-components and as a one-time operation to avoid breakage of tools, we are setting the QEMU sub-component of this BZ to "General". Please review and change the sub-component if necessary the next time you review this BZ. Thanks

Verify this issue against qemu-kvm-4.2.0-8.module+el8.2.0+5607+dc756904.x86_64

steps:
1. Boot vm with
...
<graphics type='vnc' port='5900' autoport='yes' websocket='5700' listen='0.0.0.0'>
...

2. listen to qmp events:
virsh qemu-monitor-event rhel82-virtio-vga-vnc --pretty --loop

3. connect vm through websocket

Result:
After step 3, client info has websocket enabled:
event VNC_CONNECTED at 1581471931.940828 for domain rhel82-virtio-vga-vnc: {
  "server": {
    "auth": "none",
    "family": "ipv4",
    "service": "5900",
    "host": "0.0.0.0",
    "websocket": false
  },
  "client": {
    "family": "ipv4",
    "service": "52024",
    "host": "10.72.12.24",
    "websocket": true
  }
}

event VNC_INITIALIZED at 1581471931.967591 for domain rhel82-virtio-vga-vnc: {
  "server": {
    "auth": "none",
    "family": "ipv4",
    "service": "5900",
    "host": "0.0.0.0",
    "websocket": false
  },
  "client": {
    "family": "ipv4",
    "service": "52024",
    "host": "10.72.12.24",
    "websocket": true
  }
}

Verified per comment 9

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:2017