1

有人读过 Hickson 2010 年 5 月的 draft-hixie-thewebsocketprotocol-76 WebSocket 协议吗？

这是 .htm 文件的来源：

<html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <script type="text/javascript">
        var socket = new WebSocket('ws://localhost:8181/websession');
        socket.onopen = function() {
            alert('handshake successfully established. May send data now...');
        };
        socket.onclose = function() {
            alert('connection closed');
        };
    </script>
</head>
<body>
</body>
</html>

如果我有一个监听 8181 的 TCP 端口，这是我在 Chrome 中加载上述 .htm 文件时收到的请求：

GET /websession HTTP/1.1
Upgrade: WebSocket
Connection: Upgrade
Host: localhost:8181
Origin: null
[\n]

（其中 [\n] 是 CRLF 字符。）

我应该回到这个握手开瓶器？Draft-hixie-thewebsocketprotocol-76 显示：

HTTP/1.1 101 WebSocket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Origin: http://example.com
Sec-WebSocket-Location: ws://example.com/demo
Sec-WebSocket-Protocol: sample

8jKS'y:G*Co,Wxa-

但是，此响应会导致socket.onclose触发。

4

2 回答 2

2

草案 76 将WebSocket-响应标头重命名为Sec-WebSocket-，并添加了一些不必要的丑陋Key标头和请求正文加密内容，8jKS'y:G*Co,Wxa-作为响应。但这只是草案中包含的示例的正确响应；为任何其他请求返回该特定字符串是没有好处的。有关如何实现新协议的说明，请参阅这篇文章。

在任何情况下，除非您使用最新的开发版本，否则 Chrome/Chromium 仍将使用旧的草案 75 协议（如您发布的请求所示），并且不会与实现新协议的服务器通信。有关更多信息，请参阅Chromium 博客。如果您需要支持旧的/当前的 Chrome 版本，您实际上必须实现两个 WebSocket 协议。

这始终是针对尚未标准化的协议开发东西的风险。在 WebSocket 最终确定之前，您可能会遇到烦人的互操作性；您可能更愿意推迟到那时。

（试图真正阅读规范并弄清楚在大量不可读的解析算法中到底发生了什么变化，这是一种令人沮丧的练习。我不知道为什么它是这样写的，而不是像通常的 BNF 风格规范 RFC 那样。它是就好像 Hixie 用 C 写了一个解析器，然后写了一个自动化工具来将代码转换成英文。C 本来是更易读的 TBH。）

于 2010-06-29T11:23:07.250 回答
0

您可能会发现 noVNC 中包含的 wsproxy 作为参考很有用。它透明地支持 WebSockets v75 和 v76 客户端。

wsproxy 是一个通用的 WebSockets 到 TCP 套接字代理。noVNC 包含 C 和 python 版本的 wsproxy。

http://github.com/kanaka/noVNC/tree/master/utils/

此外，为了让事情变得有趣，最新的（还没有版本）提案草案再次改变了事情（特别是它改变了事情的框架）： http: //www.whatwg.org/specs/web-socket-protocol/

于 2010-10-14T04:52:51.077 回答