- include/canvas.js: When 'debug' logging, show browser detection
  values.
- test/canvas.html: Only restore the canvas to it's starting state if
  the logging level is not 'debug'.
- wsproxy.py: Append the session number to the record filename so that
  multiple sessions don't stomp on each other.

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

This goes along with commit 7e63919e but for the C proxy.

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.

I've decided that debug/develop/extra features will just be in the
python version of the proxy. The C version (and other versions) will
just have the core functionality (unless someone wants to support it).

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.

- This allows the recorded data to be immediately usable by
  tests/vnc_playback.html

Turns out when Windows is running in QEMU and a window scroll happens,
there are lots of little hextile rects sent. This is slow in noVNC.

- Some recording/playback improvement.
- Add test harness to drive playback of recordings.
- By pulling off the rect header in one chunk we get a 3X speedup in
  Chrome and a 20% speedup in firefox (specifically for the scroll
  test).
- Also, get rid of some noise from creating timers for handle_message.
  Check to make sure there isn't already a pending timer first.

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

- When a packet with only '\xff\x00' is received, this means the
  client is doing an orderly shutdown. (WebSockets spec version 76)

Interestingly, the bug depends on compiler behavior. If local
variables are automatically initialized to 0, then this always caused
the program to error out indicating a failure to parse the listen
port. Otherwise, the test was a no-op (except the rare case where the
memory happened to be zero anyways).

Thanks to Eugen Melnikoff for finding this.

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.

Use getaddrinfo instead of gethostbyname.

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

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