Description of the WebSockets to TCP Proxy


At the most basic level, the proxy just translates WebSockets traffic
to normal socket traffic. The proxy accepts the WebSockets header,
parses it, and then begins forwarding traffic between the client and
the target in both directions.  At a minimum the proxy needs to base64
encode traffic destined for the client and decode it coming from the
client. Also, WebSockets traffic starts with '\0' (0) and ends with
'\xff' (255) so that needs to be added/stripped by the proxy.  There
is a little bit of buffering you need to do in case the data from the
client isn't a full WebSockets frame (i.e. doesn't end in 255).


Other proxy features (that aren't necessary for the basic operation):


SSL (the wss:// WebSockets URI):

This is detected automatically by the proxy by sniffing the first byte
of the client's connection and then wrapping the socket if the data
starts with '\x16' (indicating SSL).


Sequence Numbering:

When the client doesn't have native WebSockets support in the browser
(currently only Chrome and Safari 5), a flash emulator fallback is
used.  Unfortunately, when this is used, frame ordering is not 100%,
so the GET URI in the initial handshake has "seq_num=1". This tells
the proxy to add sequence numbers to every WebSockets frame so that
the browser can reorder them.


Flash security policy:

The proxy 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.


Daemonizing:

The proxy also supports daemonizing (when the -f option is not
specified).


Record:

Finally, there is a debug feature that allows recording of the traffic
sent and received from the client to a file (the --record option).