Websockets 无法解决的“收到意外的延续帧”错误答案

【问题标题】：Websockets unresolvable "received unexpected continuation frame" errorWebsockets 无法解决的“收到意外的延续帧”错误
【发布时间】：2012-05-08 00:08:38
【问题描述】：

我写了一个算法来处理 PHP 中的 Websockets 数据。从 Chrome/Firefox 解码很好，但我一直在将数据从服务器发送到客户端（Chrome 18、Websockets 13）时遇到问题。服务器例程在收到消息后自动回复“已接收”。

消息后面绝对没有其他字节，正如 STDOUT 指示和 WireShark 转储指示（通过 RawCap 检索的数据）。在 WireShark/RawCap 中，由于某种原因，server->client 消息出现在“ACK”消息下方。

我真的很感谢有人对此的见解。快把我逼疯了。

达斯汀奥普雷亚

【问题讨论】：

日志输出看起来都正确。您也可以发布您的代码吗？

标签： php firefox google-chrome websocket

【解决方案1】：

我明白了。事实证明，我最初采用的代码在握手响应标头之后的换行符之后放置了一个 NULL 字符，而我没有注意到这一点。它看起来像 a) 浏览器将所有接收到的 websocket 消息通过一个字符缓冲区移动，一旦处理了身份验证响应，该缓冲区就会在前面留下单个 NULL 字符，并且 b) 在 -next- 消息之前它不是问题收到了。

流程：

1) 浏览器（Chrome 和 Firefox）收到握手响应，最后带有一个额外的 NULL。
2) 浏览器批准握手响应。
3) 浏览器向服务器发送一条消息（在这种情况下，使用“文本”操作码，不一定重要）。
4) 服务器正确解码帧。
5) 服务器通过已建立的 websocket 会话发回消息。
6) 客户抱怨有一个意外的延续框架。

在某些情况下，我相信我能够操纵消息以抑制来自浏览器的错误，但仍然没有在浏览器中收到服务器消息。

作为上面的一个例子，我相信，最初，服务器正在发送“响应”的自动文本响应，并得到上面的消息。后来我把它改成了“1234”，还是得到了上面的信息。但是，我把这个改成“123”，就不再报错了，但是还是没有在Javascript中得到消息事件。

达斯汀奥普雷亚

【讨论】：

感谢您发布您的答案，我遇到了完全相同的问题。
@Dustin：我面临着完全相同的问题。发送数据时你是如何找出多余的空字符的。？
@Sony 我不太记得了。这很令人沮丧，但我想我最终专门检查了 NULL。
这是我使用的众多 phpwebsocket 克隆之一遇到的问题之一。从 do_handshake() 代码的末尾删除了 chr(0)。我还需要握手中的 Sec-WebSocket-Accept 标头才能使 Chrome 正常工作。另一件事是，我还从另一个 websocket 实现中移植了 hybi10Decode() 和 hybi10Encode() 函数，以便更轻松地支持 RFC。