- 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).
host and port where the proxy is running and the password that the
vnc server is using (if any). Hit the Connect button.
+* If you are using python 2.3 or 2.4 and you want wsproxy to support
+ 'wss://' (TLS) then see the
+ [wsproxy README](http://github.com/kanaka/noVNC/blob/master/utils/README.md)
+ for instructions on building the ssl module.
+
### Integration
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>.
+++ /dev/null
-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).
--- /dev/null
+## 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 `-f` option 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 `--record`
+ option.
+
+
+### Implementations
+
+There are two implementations of wsproxy included: a python
+implementation and a C implementation.
+
+Here is the feature support matrix for the wsproxy implementations:
+
+
+<table>
+ <tr>
+ <th>Implementation</th>
+ <th>Basic Proxying</th>
+ <th>Daemonizing</th>
+ <th>SSL/wss</th>
+ <th>Flash Policy Server</th>
+ <th>Session Recording</th>
+ </tr> <tr>
+ <td>python</td>
+ <td>yes</td>
+ <td>yes</td>
+ <td>yes 1</td>
+ <td>yes</td>
+ <td>yes</td>
+ </tr> <tr>
+ <td>C</td>
+ <td>yes</td>
+ <td>yes</td>
+ <td>yes</td>
+ <td>yes</td>
+ <td>no</td>
+ </tr>
+</table>
+
+* 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/utils
+ wget http://pypi.python.org/packages/source/s/ssl/ssl-1.15.tar.gz
+ tar xvzf ssl-1.15.tar.gz
+ cd ssl-1.15
+ make
+ cd ../
+ ln -sf ssl-1.15/build/lib.linux-*/ssl ssl
+
projects / mirror_novnc.git / commitdiff