Issue #32, wsproxy README, update webkit bug info,

- Add wsproxy README.md in utils/ directory.

- Document how to build ssl module for python 2.5 and older in wsproxy
  README.

- Update browsers.md to note revision that have the webkit Canvas
  rendering bug: WebKit build 66396 through 68867 (Chrome/Chromium
  build 57968 through 61278).

2 files changed, 3 insertions, 56 deletions

diff --git a/docs/browsers.md b/docs/browsers.md
index 75a044c..ad52fd3 100644
--- a/docs/browsers.md
+++ b/docs/browsers.md
@@ -116,9 +116,9 @@
   accepting the certificate. Then return to noVNC and connect
   normally.
 
-* Note 3: Browsers using WebKit build 66396 or later
-  (Chrome/Chromium after build 57838) have a Canvas rendering bug. The
-  WebKit bug is <a
+* Note 3: Browsers using WebKit build 66396 through 68867
+  (Chrome/Chromium build 57968 through 61278) have a Canvas rendering
+  bug. The WebKit bug is <a
   href="https://bugs.webkit.org/show_bug.cgi?id=46319">#46319</a>.
   The noVNC bug is <a
   href="http://github.com/kanaka/novnc/issues/#issue/28">#28</a>.
diff --git a/docs/proxy_description.txt b/docs/proxy_description.txt
deleted file mode 100644
index 83dfb1c..0000000
--- a/docs/proxy_description.txt
+++ /dev/null
@@ -1,53 +0,0 @@
-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).