6b900d25d0
Interpose on select/pselect so that WebSockets sockets are only reported as ready if they have enough to actually decode at least 1 byte of real data. This prevents hanging in read/recv after WebSocket is reported as ready but is not actually ready because empty frames or less than four base64 bytes have been received. Split defines and constant defintions into wswrapper.h. Cleanup debug output and add TRACE for more detailed tracing debug output. Major TODO is that select needs to timeout if WebSocket socket keeps reporting ready but actually isn't ready. That condition will currently hang forever because the select timeout value is not adjusted when looping. |
||
|---|---|---|
| .. | ||
| Makefile | ||
| README.md | ||
| launch.sh | ||
| md5.c | ||
| md5.h | ||
| md5_test.c | ||
| web.py | ||
| websocket.c | ||
| websocket.h | ||
| websocket.py | ||
| wsproxy.c | ||
| wsproxy.js | ||
| wsproxy.py | ||
| wswrap | ||
| wswrapper.c | ||
| wswrapper.h | ||
README.md
wsproxy: WebSockets to TCP Proxy
How it works
At the most basic level, wsproxy just translates WebSockets traffic to normal socket traffic. wsproxy accepts the WebSockets handshake, parses it, and then begins forwarding traffic between the client and the target in both directions. WebSockets payload data is UTF-8 encoded so in order to transport binary data it must use an encoding that can be encapsulated within UTF-8. wsproxy uses base64 to encode all traffic to and from the client. Also, WebSockets traffic starts with '\0' (0) and ends with '\xff' (255). Some buffering is done in case the data from the client is not a full WebSockets frame (i.e. does not end in 255).
Additional features
These are not necessary for the basic operation.
-
Daemonizing: When the
-foption is not specified, wsproxy runs in the background as a daemon process. -
SSL (the wss:// WebSockets URI): This is detected automatically by wsproxy by sniffing the first byte sent from the client and then wrapping the socket if the data starts with '\x16' or '\x80' (indicating SSL).
-
Flash security policy: wsproxy detects flash security policy requests (again by sniffing the first packet) and answers with an appropriate flash security policy response (and then closes the port). This means no separate flash security policy server is needed for supporting the flash WebSockets fallback emulator.
-
Session recording: This feature that allows recording of the traffic sent and received from the client to a file using the
--recordoption.
Implementations
There are three implementations of wsproxy included: python, C, and Node (node.js).
Here is the feature support matrix for the wsproxy implementations:
| Implementation | Basic Proxying | Multi-process | Daemonizing | SSL/wss | Flash Policy Server | Session Recording |
|---|---|---|---|---|---|---|
| python | yes | yes | yes | yes 1 | yes | yes |
| C | yes | yes | yes | yes | yes | no |
| Node (node.js) | yes | yes | no | no | no | no |
- Note 1: to use SSL/wss with python 2.5 or older, see the following section on Building the Python ssl module.
Building the Python ssl module (for python 2.5 and older)
-
Install the build dependencies. On Ubuntu use this command:
sudo aptitude install python-dev bluetooth-dev -
Download, build the ssl module and symlink to it:
cd noVNC/utilswget http://pypi.python.org/packages/source/s/ssl/ssl-1.15.tar.gztar xvzf ssl-1.15.tar.gzcd ssl-1.15makecd ../ln -sf ssl-1.15/build/lib.linux-*/ssl ssl