just tried to implement the server side of a Web Sockets implementation ontop of Wisp. It was surprisingly easy and code-efficient compared to my efforts on other languages, though I did run into one roadblock:
The initial handshake response for a standards-based WebSocket is:
HTTP/1.1 101 Web Socket Protocol Handshake
The spec is here - http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-54
Unfortunately in Fantom the status message for a code 101 is hard-coded to "Switching Protocols". The Web Socket implementation is very specific in that it requires exactly the above handshake, and indeed this is how Chrome seems to have implemented it.
Using the standard Fantom WebRes status message, chrome breaks off at the first line with a javascript exception "Unexpected response code:101". Recompiling Fan with an amended status message yields a successful bi-directional communication between the browser and Wisp.
I'd like to thank katox on IRC for helping me get fantom recompiled ;-)
Niel
brianMon 17 May 2010
Eventually I'd like to have a full API for supporting WebSockets (on both client and server).
But the in meantime, as a quick fix for this issue I propose that Wisp will automatically use "Web Socket Protocol Handshake" as the response status message for 101 if it also detects the "Upgrade: WebSocket" response header.
i can confirm the new code sends the correct headers on my test case, unfortunately the connection closes right after the connection is established (on the client the state switches to WebSocket.CLOSED, and WebSocket.send then evaluates to false).
it's a promising start, and i will post if i find out some more information.
grumpytoad Mon 17 May 2010
Hello,
just tried to implement the server side of a Web Sockets implementation ontop of Wisp. It was surprisingly easy and code-efficient compared to my efforts on other languages, though I did run into one roadblock:
The initial handshake response for a standards-based WebSocket is:
HTTP/1.1 101 Web Socket Protocol Handshake
The spec is here - http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-54
Unfortunately in Fantom the status message for a code 101 is hard-coded to "Switching Protocols". The Web Socket implementation is very specific in that it requires exactly the above handshake, and indeed this is how Chrome seems to have implemented it.
Using the standard Fantom WebRes status message, chrome breaks off at the first line with a javascript exception "Unexpected response code:101". Recompiling Fan with an amended status message yields a successful bi-directional communication between the browser and Wisp.
An example for a client request is here:
http://blog.chromium.org/2009/12/web-sockets-now-available-in-google.html
I'd like to thank katox on IRC for helping me get fantom recompiled ;-)
brian Mon 17 May 2010
Eventually I'd like to have a full API for supporting WebSockets (on both client and server).
But the in meantime, as a quick fix for this issue I propose that Wisp will automatically use "Web Socket Protocol Handshake" as the response status message for 101 if it also detects the "Upgrade: WebSocket" response header.
Any comments before I do that change?
brian Tue 18 May 2010
I pushed a patch for this change - changeset
grumpytoad Thu 20 May 2010
i can confirm the new code sends the correct headers on my test case, unfortunately the connection closes right after the connection is established (on the client the state switches to WebSocket.CLOSED, and WebSocket.send then evaluates to false).
it's a promising start, and i will post if i find out some more information.