views:

469

answers:

2

Has anyone read Hickson's May 2010 draft-hixie-thewebsocketprotocol-76 WebSocket protocol?

Here is the the source of an .htm file:

<html>
<html xmlns="http://www.w3.org/1999/xhtml"&gt;
<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>

If I have a TCP port listening on 8181, this is the request I get when I load the .htm file above in Chrome:

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

(Where [\n] is CRLF character.)

What should I return to this handshake opener? draft-hixie-thewebsocketprotocol-76 shows:

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-

This response causes socket.onclose to fire though.

+2  A: 

Draft 76 renamed the WebSocket- response headers to Sec-WebSocket-, and added some unnecessarily ugly Key header and request body crypto stuff to which the 8jKS'y:G*Co,Wxa- is a response. But that's only the correct response for the example included in the draft; it's no good returning that specific string for any other request. See this post for an explanation of how to implement the new protocol.

In any case, unless you are using the latest development builds, Chrome/Chromium will still be using the old draft 75 protocol (as the request you posted demonstrates), and won't talk to the a server that implements the new protocol. See the Chromium blog for more info. If you need to support old/current Chrome versions you effectively have to implement two WebSocket protocols.

This is always the risk in developing stuff against a protocol that is not yet standardised. You can expect annoying interinoperability until WebSocket is finalised; you may prefer to hold off until then.

(Trying to actually read the spec and work out what exactly has changed amongst the reams of unreadable parsing algorithms, is an exercise in frustration. I have no idea why it is written like this instead of the usual BNF-style specifications RFCs like. It's as if Hixie wrote a parser in C and then wrote an automated tool to turn the code into English. C would have been more readable TBH.)

bobince
A: 

You might find the wsproxy included in noVNC to be useful as a reference. It transparently supports both WebSockets v75 and v76 clients.

wsproxy is a generic WebSockets to TCP socket proxy. There is both a C and python version of wsproxy included with noVNC.

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

Also, just to keep things interesting, the latest (no version yet) draft proposal changes things up again (in particular it changes how things are framed): http://www.whatwg.org/specs/web-socket-protocol/

kanaka