This commit should fix#101 by enabling a special SIGCHLD
handler for when multiprocessing is in use. The handler
simply calls `multiprocessing.active_children()` (which in
turn calls `_cleanup()`) upon receiving a SIGCHLD. Now,
the `fallback_SIGCHLD` is only called when `multiprocessing`
is not in use. See also #95.
WebSocketServer is a library module, as such, it cannot assume it can
write output to process stdout.
Python logging module is designed in order to allow subscribers to
handle the output out of modules. It is simple and generic mechanism to
separate between data producer and data handling.
Python logging API also has the nature of log level, so the verbose
parameter can probably be obsoleted in favor of logging level. And of
course the logging API has built in support for exception tracebacks, no
need for manual format.
Per upstream request a wrapper is created around python logging to
enable shorter statements and optional replacement.
Add --traffic parameter for traffic specific debug, this is required as
it uses direct unformatted stdout output.
Signed-off-by: Alon Bar-Lev <alon.barlev@gmail.com>
WebSocketServer is a library module, as such it should not exit process
but return from a method, allowing the caller to execute process show
down.
Signed-off-by: Alon Bar-Lev <alon.barlev@gmail.com>
WebSocketServer is a library module, as such it should try to restore state
after processing, to allow caller to resume normal operation.
Signed-off-by: Alon Bar-Lev <alon.barlev@gmail.com>
The WebSocketProxy class is usable for creating derived applications
with different logic, especially for the target validation.
Current code assumes that target is a path while in other implementation
it can be object that is loaded at initialization.
This change moves the conversion to absolute path into main function, so
that the WebSocketProxy class will not make that assumption.
Signed-off-by: Alon Bar-Lev <alon.barlev@gmail.com>
Update both the submodule and the swf build. The submodule now
contains the unobfuscated source for swfobject.js which should make
websockify more DFSG compliant.
This patch adds 2 arguments to websockify.WSRequestHandler for security:
* file_only: returns 404 response if non-file contents are requested.
Required to disable directory listing.
* no_parent: returns 403 response if contents out of the web root are
requested. Required to disable directory traversal.
*** 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.
Solly Ross