WebSocket：未拒绝未掩码的客户端帧、也未校验文本帧 UTF-8（两条 RFC 6455 MUST） #8

两条 RFC 6455 的 MUST 没有实现：未掩码的客户端帧、非法 UTF-8 的文本帧

在 master（1.1.7，本地从源码构建）上打 WebSocket 协议一致性时发现的。解析器只对这两条不做校验，其余都做了 —— 所以这不是"WS 实现不完整"，而是两个具体的检查漏了。

1. 未掩码的客户端帧被当成正常消息

发送：一个掩码位为 0 的合法 TEXT 帧（内容 "unmasked"）
实测：服务端把它原样回显了（收到 data b'unmasked'）
期望：以 1002 关闭连接

RFC 6455 §5.1：

The server MUST close the connection upon receiving a frame that is not masked.
... a server MUST use the 1002 status code.

掩码存在的理由就是防中间代理缓存投毒（§10.3），所以服务端不强制等于把这条防护让掉。

2. 非法 UTF-8 的文本帧被原样回显

发送：TEXT 帧，负载是 \xff\xfe\xfd（不是合法 UTF-8）
实测：服务端原样回显（收到 data b'\xff\xfe\xfd'）
期望：以 1007 关闭

RFC 6455 §8.1：

When an endpoint is to interpret a byte stream as UTF-8 but finds that the byte stream is not, in fact, a valid UTF-8 stream, that endpoint MUST Fail the WebSocket Connection.

对照组：其余校验都是对的

所以校验框架是在的，只是这两条没有。

代码位置与建议改法

掩码：src/web/uvcpp_ws_connection.cpp 里控制帧/数据帧是在一处分支里分开处理的（switch (frame.opcode) 那一支是控制帧，之后是数据帧）。掩码检查要在这个分叉之前做 —— 它对所有帧类型都适用（控制帧也必须掩码，§5.5）：

// 服务端：客户端发来的帧必须掩码（RFC 6455 §5.1）。
// 注意方向：客户端一侧反过来 —— 服务端发来的帧必须**不**掩码，同样是 1002。
if (is_server_side() && !frame.masked) {
  protocol_error(ws_close_code::PROTOCOL_ERROR, "client frame must be masked");
  return;
}

（uvcpp_ws_parser 现在是"有掩码就解、没有也不拒" —— parse_frame_header 里 if (frame_.masked) { state_ = MASK_KEY; ... }，缺一个方向性的要求。因为解析器两边共用，这个判断放在连接层更合适，需要知道自己是服务端还是客户端。）

UTF-8：deliver_message() 里，解压之后、调 on_text_ 之前，正好是校验点 —— 校验的必须是应用将要看到的那份字节（压缩时必须验解压后的）：

if (op == ws_opcode::TEXT) {
  if (!is_valid_utf8(data, len)) {
    message_payload_.clear();
    protocol_error(ws_close_code::INVALID_PAYLOAD, "text frame is not valid UTF-8");
    return;
  }
  ...
}

INVALID_PAYLOAD（1007）这个关闭码文件里已经在用了（permessage-deflate 解压失败那一支），所以不用新增任何基础设施。

（严格说 §8.1 还要求分片文本边收边校验，好在坏字节到达时就失败；但"消息收完再验"已经满足"MUST Fail the Connection"这条主要要求，实现成本也低得多。可以先把这条补上。）

复现

两条都不需要特殊工具，一个裸 socket 就能发：

# 未掩码的 TEXT 帧（fin=1, opcode=1, mask=0, len=8）
sock.sendall(bytes([0x81, 0x08]) + b"unmasked")
# 非法 UTF-8 的 TEXT 帧（fin=1, opcode=1, mask=0, len=3）
sock.sendall(bytes([0x81, 0x03]) + b"\xff\xfe\xfd")

完整探查脚本（7 条，含上面那组对照）我这边有，需要的话可以贴上来或者整理成一个 tests/functional/ 下的用例。

影响评估

两条都是一致性缺陷，不是内存/崩溃类问题：

• 未掩码：服务端本身不会因此出错，但它放掉的是"客户端必须掩码"这条约束 —— 在中间代理存在时，这正是掩码要防的场景。
• 非法 UTF-8：服务端只是转发字节，自己不受影响；但一个把文本原样转给浏览器的应用（聊天室这类）会把非法字节传下去，客户端那边才炸。

两条都不难改，改动集中在 uvcpp_ws_connection.cpp，不需要动解析器。