Question

有没有人读过希克森2010年5月的草案-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触发。

Answer 1

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

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

对于尚未标准化的协议开发内容总是存在风险。在WebSocket最终确定之前，您可能会遇到恼人的互操作性;你可能希望在那之前推迟。

（试图实际阅读规范并找出大量不可读的解析算法之间的变化，这是一种令人沮丧的练习。我不知道为什么它是这样编写而不是通常的BNF风格的规范RFC就好像Hixie在C中编写了一个解析器然后编写了一个自动化工具来将代码转换成英文.C本来是更具可读性的TBH。）

Answer 2

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

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

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

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

HTML5：最新的WebSockets

2 个答案: