Addresses this issue:
http://github.com/kanaka/noVNC/issues#issue/14

Safari starts with '\x80' rather than '\x16' like Chrome and Firefox
and having PROTOCOL_TLSv1 doesn't work with Safari. But just removing
the ssl_version allows things to work with Safari wss:// connections.

Also, if the handshake (after SSL wrapping) is null then terminate the
connection. This probably means the certificate was refused by the
client. Unfortunately Safari (the version I have) doesn't cleanly
shutdown WebSockets connections until the page is reloaded (even if
the object is no longer referenced).

Always fork handlers processes. Instead printing traffic when
single-processing, print traffic if verbose flag given.

Add -m, --multiprocess option which forks a handler for each
connection allowing multiple connections to the same target using the
same proxy instance.

Cleaned up the output of the handler process. Each process' output is
prefixed with an ordinal value.

Changed both the C and python versions of the proxy.

It's less efficient on average that base64 (150% vs 133%). It's
non-standard (0 shifted to 256 before encoding). And I rarely use it.

- Fallback to md5 module if hashlib not there.
- Import parse_qsl from cgi where it is in both 2.4 and 2.6

- Replace URL parsing using "".partition() with urlparse module.

The listen port should be opened before daemonizing otherwise if
opening the port fails, the user will get no feedback. The only
complication was that the listen socket needs to not be closed as part
of daemonizing.

Thanks to http://github.com/rickr for finding it.

Pull in LGPL md5.c and md5.h files (written by Ulrich Drepper).

Now both python and C version of the proxy support both protocol 75
and protocol 76 (hybi 00).

Reorganize websocket.py slightly to match websocket.c.

Looks like disabling web-socket-js debug messages by default that we
get a minor speedup.

Python proxy should support both 75 and 76 (00) modes. Also, update ws
test to more reliably hit the WebSockets ordering/drop issue.

Refactor how settings are passed around.

This allows forwarding from an external port to the same port on
localhost (loopback). I.e.

./utils/wsproxy `hostname -f`:5901 localhost:5901

Also add a wsencoding test client/server program to test send a set of
values between client and server and vice-versa to test encodings.

Not turned on by default.

Add support for encode/decode of UTF-8 in the proxy. This leverages
the browser for decoding the WebSocket stream directly instead of
doing base64 decode in the browser itself.

Unfortunately, in Chrome this has negligible impact (round-trip time
is increased slightly likely due to extra python processing).

In firefox, due to the use of the flash WebSocket emulator the
performance is even worse. This is because it's really annoying to get
the flash WebSocket emulator to properly decode a UTF-8 bytestream.
The problem is that the readUTFBytes and readMultiByte methods of an
ActionScript ByteArray don't treat 0x00 correctly. They return
a string that ends at the first 0x00, but the index into the ByteArray
has been advanced by however much you requested.

This is very silly for two reasons: ActionScript (and Javascript)
strings can contain 0x00 (they are not null terminated) and second,
UTF-8 can legitimately contain 0x00 values. Since UTF-8 is not
constant width there isn't a great way to determine if those methods
in fact did encounter a 0x00 or they just read the number of bytes
requested.

Doing manual decoding using readUTFByte one character at a time slows
things down quite a bit. And to top it all off, those methods don't
support the alternate UTF-8 encoding for 0x00 ("\xc0\x80"). They also
just treat that encoding as the end of string too.

So to get around this, for now I'm encoding zero as 256 ("\xc4\x80")
and then doing mod 256 in Javascript. Still doesn't result in much
benefit in firefox.

But, it's an interesting approach that could use some more exploration
so I'm leaving in the code in both places.

- Otherwise client_setting carry over from other connections.