| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|\ \ \ \ \
| | | | | |
| | | | | | |
Fix for errors that occur when closing websocket from another thread
|
| |/ / / /
| | | | |
| | | | | |
https://github.com/websocket-client/websocket-client/issues/449
|
| | | | | |
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Fix getting 400 bad request with long proxy authorization string
|
| |/ / / / |
|
|\ \ \ \ \
| | | | | |
| | | | | | |
wsdump: Fix --headers option
|
| |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Since https://github.com/websocket-client/websocket-client/pull/506
changes the way that options['header'] is used, it breaks --headers
option of wsdump command because wsdump command uses a map object
instead of a list here, which can only be used once. Therefore, after
the first use with 'not in' operator, it becomes empty and no headers
specified by the user are sent.
To fix it, simply convert the map object into a list, so it can be use
multiple times.
|
|/ / / / |
|
|/ / / |
|
| | | |
|
|\ \ \
| |/ /
|/| | |
Don't retry sockets with timeout set to 0
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
For non-blocking sockets with the timeout set to 0, the select call in
_recv and _send will return immediately without the socket being ready.
This causes _recv to return None, which makes recv close the connection.
Since a select with a timeout of 0 right after recv/send is pointless,
just skip _recv and _send when timeout is 0.
As for the handling of SSLWantReadError, SSLWantWriteError, EAGAIN and
EWOULDBLOCK in _recv/_send, websocket-client can't handle these without
blocking. Since applications which has timeout set to 0 don't want
websocket-client to block them, they have to handle those errors
themselves.
Fixes #535
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In multi-threaded environment where the `WebsocketApp` lives in another thread
than the main thread, the main thread might call `WebsocketApp.close` which
will sends the closing message to the backend and then wait for the answer.
This will likely makes the following loop
https://github.com/websocket-client/websocket-client/blob/master/websocket/_app.py#L49
to ends which will calls
https://github.com/websocket-client/websocket-client/blob/master/websocket/_app.py#L235.
The second call will happened in the `WebsocketApp` thread and as the socket
is already marked as not connected anymore, the second thread will jump
directly into the `WebSocket.shutdown` method which will abruptly close the
socket, stopping all in-progress sending and making the first call to
`WebSocket.close` to crash as `self.sock` is replaces by None.
|
| | | |
|
|\ \ \ |
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When connecting to a socket, EINTR ("Interrupted system call") may be
raised if the application receives a signal at the same time. Prior to
Python 3.5, applications has to handle this themselves by retrying the
connection. For more details, see https://www.python.org/dev/peps/pep-0475/
Fixes #527
|
|\ \ \ |
|
| |\ \ \ |
|
| | |/ /
| | | |
| | | |
| | | |
| | | | |
Note: that still leaves "subprotocols", "header", "cookie", "origin"
and "host" values in a bugged state (they are NOT passed down).
|
| | | | |
|
| | | | |
|
|\ \ \ \
| |/ / / |
|
| |\ \ \ |
|
| | |/ / |
|
|/ / / |
|
| | | |
|
|\ \ \
| |/ /
|/| | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* Fix ssl socket handling
Handle them as recommended in here
https://bugs.python.org/issue21430 and in
python documentation. Do not use undocumented
SSLSocket pending
* Increase version
|
| | | |
|
|\ \ \ |
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | | |
When manually assigning `Sec-WebSocket-Key` & `Sec-WebSocket-Version`, websocket-client would raise:
WebSocketException("Invalid WebSocket Header")
Because the key for instance, would be inserted twice.
The best way to get around this in the long run, would be to refrain from using lists as the header builder, since keys can't occur twice anyway. Thus, just creating the automated headers first, and then iterating over whatever the user inputs - would effectively replace any default headers automatically, without needing to parse "if host in options['headers']" etc. Just iterate over the headers given, replace the default ones and bam, profit.
|
| | | |
|
| | | |
|
|\ \ \
| |/ /
|/| | |
|
|/ / |
|
| | |
|
| | |
|
| | |
|
| | |
|
|\ \ |
|
| |\ \ |
|
| | | | |
|
|\ \ \ \
| |/ / / |
|
| |\ \ \
| | | | |
| | | | | |
Fix typo in supress_origin
|
| | |\ \ \
| | |/ / /
| |/| | | |
|
| | |/ / |
|
|/ / / |
|
| | | |
|