Updated to master, use manual logging configuration #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If no length parameter is given to rQshiftStr or rQshiftBytes, then the all remaining data (the full length) will be shifted off. Also, honor the window.WEB_SOCKET_FORCE_FLASH variable to force web-socket-js to be used even if the browser has native WebSockets support.
Pull 63aa9ce07 from https://github.com/kumina/wsproxy
Signed-off-by: Chris Gordon <[email protected]>
Pruned binary files.
Need to detect leading TLS/SSL character by number too for python 3.
This current code accepts WebSocket connections and can send data back and forth.
Still needs some cleanup related to cleaning up client and target connections.
Also, disable verbose debug.
Generic TCP client and Websocket server code is now split out from the websockify specific code.
Can now be launched like so: lein run websockify --web ../../noVNC/ 6080 localhost:5901
It's probably broken and it's definitely still messy in several ways, but basic tests work with Chrome. Several other C websockify cleanups: - Remove most of the non-thread safe global variable usage (still a little bit that could be fixed so that threading would be easier). - Remove wswrapper. It is unmaintained, out of date, and never worked well anyways (since it really needed a way to do asynchronous queued work but it was running in another process context making that hard). - Use md5 routines from openssl. - Remove md5.c and md5.h since no longer needed. Thanks to https://github.com/dew111 for spurring me on to get this done by writing code. I didn't end up using much his forked code, but having something there goaded me enough to just get it working.
Significant refactor of decode_hybi() and use of it in do_proxy().
- Rename unix socket option to '--unix-target' to be consistent with '--ssl-target' which is an analogous switch. - Fix normal socket target mode which was broken after merge. - Normalize/fix output for SSL, unix socket and wrap command modes.
- The --web option changes directory so the wrap mode needs to get an absolute path to the rebinder. - Also, use long instead of int in rebind.c so avoid compile warnings.
Mostly it is based on the project README.md but with some tweaks and extra content removed. Thanks for Adam Young <[email protected]> for the original version of this. Also a decent man format reference is here: http://www.fnal.gov/docs/products/ups/ReferenceManual/html/manpages.html
Parse square brackets-enclosed IPv6 for 'source_addr' and 'target_addr' parameters.
Add the option "-6, --prefer-ipv6". When set, the 'prefer_ipv6' flag in websocket.py is used so that 'source_addr' is resolved to IPv6 if available. If 'source_addr' is not set, binds to [::].
Better support of IPv6
…uration file. The --target-list option is used to pass a configuration file on websockify start. This file contains entries in the form host:port:token, one per line. When a new connection is open (from noVNC for example), the url should look like: ws://websockify_host:websockify_port/?token=ABCD The token is then extracted and checked against the entries in the configuration file. When the token matches, the connection is proxied to the host:port indicated in the file. If the configuration file is a folder, then all the entries from files in it are read.
websocket.py has no concept of target/proxy so any target processing should happen in websockify itself. Also: - remove URL parsing imports from websocket.py since they are not needed with SimpleHTTPRequestHandler doing the parsing. - read the absolute path of the target_list file on startup since the --web option will change directories if set.
Config file syntax is now like this:
----------------------
# Comments and blank lines are allow
token1: host1:port1
token2: host2:port2
----------------------
This makes it easier to use the websocket code in a WSGI script in the future.
Need the scheme to be accessible when constructing the response for Hixie clients.
If typed arrays (arraybuffers) are available and the WebSocket implementation supports them, then send and receive direct binary frames and skip base64 encode/decode. Otherwise we just fallback to the current method of sending base64 encoded strings (with a couple of extra checks for mode in the send/receive path). The check for binaryType support in WebSocket is a collosal hack right now due to the fact that the 'binaryType' property doesn't exist on the WebSocket prototype. So we have to create a connection to a localhost port in order to test. A potentionally big performance boost could probably be achieved by re-using a larger typed array for storing the data instead of creating a typed array every time we receive a message.
Instead of trying to handle the receive queue as a typed array, just replace the base64 encode/decode with conversion from/to typed arrays and handle the receive and send queue as before (plain Javascript arrays). There is a lot of opportunity here for optimization of course, but for now it's more important that it work properly.
If no protocols are selected then defaults to ['binary', 'base64'] (or just 'base64' if there is not full binary type support. Checks to make sure binary types are fully supported and throws an exception if they are requested but not supported.
server exits after TIMEOUT seconds if there are no active connections
Implement --idle-timeout for issue novnc#55
msg and vmsg now uses self.log.* Log initialization now in websockify
|
Sorry again, but I just realized I pushed the wrong local branch when I was making this PR. This is the right one, that actually includes @tomas-edwardsson's logging code this time. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Sorry it took so long to get back to you, but I've done a bunch of testing with your logging code and everything seems to work. I added logging code to a few of the tests and have it tested and working with my company's software. Also, it's updated to the latest upstream master, so that should help you get it merged upstream.
I changed us over to using manual logging configuration instead of just basicConfig because something in my production code was ignoring the basicConfig settings. Not sure what, but it works with manual setup.