TypeError: exceptions must be old-style classes or derived from
BaseException, not str
Thus, we are not allowed to raise a string. Raise Exception instead.
refactoring. Basically, we are dividing WebSocketServer into two
classes: One request handler following the SocketServer Requesthandler
API, and one optional server engine. The standard Python SocketServer
engine can also be used.
websocketproxy.py has been updated to match the API change. I've also
added a new option --libserver in order to use the Python built in
server instead.
I've done a lot of testing with the new code. This includes: verbose,
daemon, run-once, timeout, idle-timeout, ssl, web, libserver. I've
tested both Python 2 and 3. I've also tested websocket.py in another
external service.
Code details follows:
* The new request handler class is called WebSocketRequestHandler,
inheriting SimpleHTTPRequestHandler.
* The service engine is called WebSocketServer, just like before.
* do_websocket_handshake: Using send_header() etc, instead of manually
sending HTTP response.
* A new method called handle_websocket() upgrades the connection to
WebSocket, if requested. Otherwise, it returns False. A typical
application use is:
def do_GET(self):
if not self.handle_websocket():
# handle normal requests
* new_client has been renamed to new_websocket_client, in order to
have a better name in the SocketServer/HTTPServer request handler
hierarchy.
* Note that in the request handler, configuration variables must be
provided by the "server" object, ie self.server.target_host.
Move around functions and methods, so that connection-related and
server-related stuff are close together.
This patch just moves things around - it does not change anything at
all. This can be verified with:
git diff websocket.py | grep ^- | cut -c 2- | sort > removed
git diff websocket.py | grep ^+ | cut -c 2- | sort > added
diff -u removed added
*** IMPORTANT NOTE ***
0.4.X is the last minor version to support the Hixie protocol. 0.5.0
will drop the Hixie protocol support. The latest released version of
all major browsers (and web-socket-js) support the IETF 6455 protocol.
- Other changes: add 'include/' sub-dir to source distribution and to
installed packaged.
*** IMPORTANT NOTE ***
This is the last minor version to support the Hixie protocol. I may do
bug fixes (e.g. 0.4.1) but 0.5.0 will drop the Hixie protocol support.
The latest released version of all major browsers (and web-socket-js)
support the IETF 6455 protocol.
- Other changes: updating TODO and release process notes.
If WebSocketServer is used as a library with run_once or timeout, then
cleanup the socket listener socket so that when start_server returns
(due to run_once or timeout) then port is freed up.
Should at least mostly address this issue:
https://github.com/kanaka/websockify/issues/63
The problem is that the target in the test case often immediately
closed the target after sending the data. In this case the last data
received from the target is never sent to the client because the
client is not in the list of sockets being selected against (because
it is only added if their is pending data). By moving the client
conditionals first, we give the client socket a chance to be sent data
before the target is detected as close and we terminate the loop.
This works a bit differently than python websockify implementation
since the server either runs in HTTP or in HTTPS and both web and
websocket servers only support the same mode. Specifying the --cert
parameter activates encrypted HTTPS/WSS mode.
Instead of using apply with the Uint8Array to push the data onto the
receive queue, iterate through the binary data and push it an element
at a time. Apparently, doing an apply with a very large binary array
can blow the stack. Performance-wise this seems equivalent in Chrome
22 and Firefox 16.
This version requires a patched version of einaros/ws that can be
found here: https://github.com/kanaka/ws You can use the patched
version like this:
cd websockify/other
git clone https://github.com/kanaka/ws
npm link ./ws
Once the upstream 'ws' module supports subprotocol negotiation then
this will no longer be necessary.
Changes:
- Adds support for binary data and subprotocol negotiation of 'base64'
vs 'binary' with 'binary' preferred if the client offers it.
- Add client address to log messages.
- Close the target when the client closes.
- Catch errors when we try and send to a client that is no longer
connected.
Fix recording so that it records the actual payload bytes sent to the
client. This means that if the client and server and using base64
encoding then the captured data will still be base64 encoded. However,
data received from the client is unmasked when recorded. Note that
this is not done efficiently; when recording, client data is unmasked
twice (once for sending on to the target and once for recording). This
could be made more efficient but that would require a refactor of how
frame reception and unmasking works and recording is not considered
a performance sensitive mode.
Sync with noVNC ad29479ca90f9. Use new dynamic script loading
mechanism in util.js.
window.onscriptsload is called when dynamic scripts have loaded
(window.onload fires too early in IE 9).
The MPL 2.0 license is a "file-level" copyleft license vs the
"project-level" nature of the L/GPL. The intention of the websock.js
file has always been that it should be easy to incorporate into
existing projects and sites whether free/open or
proprietary/commercial. The MPL 2.0 is designed for this sort of
combination project but still requires that any distributed
modifications to noVNC source files must also be published under the
same license.
In addition, the MPL 2.0 allows the code to be used in L/GPL projects
(the secondary license clause). This means that any projects that are
already incorporating noVNC should not be impacted by this change and
in fact it should clarify the licensing situation (the exact
application of the L/GPL to web applications and interpreted code is
somewhat ambiguous).
The dependencies on include/websock.js are also updated to MPL 2.0
including util.js and webutil.js. The base64.js has been updated to
the MPL 2.0 licensed version from Mozilla.
The websockify python code (and other implementations) remain under
a LGPLv3 license.
Old users of the websockify library used websockify.WebSocketProxy
The refactor into a module unneccessarily broke this import. The
current imports in __init__.py don't actually do anything so this
patch changes the import to import everything so that the old import
still works. This appears to be the original intention of the existing
import statements.
Python ignores SIGPIPE on startup, because it prefers to check every
write and raise an IOError exception rather than taking the signal. Most
Unix subprocesses don't expect to work this way. This patch (adapted
from Colin Watson's post at http://tinyurl.com/2a7mzh5) sets SIGPIPE
back to the default action.
If a protocol list is specified and we don't support binary WebSockets
then strip binary from the list and check the list to make sure there
is still an option left.
Make websockify subdirectory and move websocket.py ->
websockify/websocket.py and websockify ->
websockify/websocketproxy.py. Create a ./run script that launches
websockify as before (unfortunately can't have a websockify script at
the same level since this is now a directory). Make websockify.py
a symlink to ./run. Once the package is installed, the main launch
script will be /usr/bin/websockify.
This makes it easier to package up websockify as a python module.
setup.py should now properly install websockify as a module.
Note that to include the base websocket module/class you will now do:
import websockify.websocket
#OR
from websockify.websocket import WebSocketServer
To import the full websocket proxy functionality:
import websockify.websocketproxy
#OR
from websockify.websocket import WebSocketProxy
This will also help with startup speed slightly because the code in
websocketproxy will now be byte compiled since it is no longer in the
main invocation script.