You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have read issue #700 and read the argument the ucrrent implementation is "more flexible". Having been burnt with this just recently I would argue the inconsistency is worse.
If you use a black box application that includes requests and then adds websocket support using this library things go horribly wrong. I eventually traced the issues to the nigh on unique approach websockets takes to handling no_proxy.
Please read the "lowest common denominator" which unfortunately the websocket-client does not meet. I was religously following this.
Googles gcloud supports proxies and I had been using it for years with no_proxy with domains with no ".". All was well until 2 weeks ago when i started using a new feature for tunnelling that uses this client. This was the only feature that did not work. It took me debugging the gcloud to eventually work out this library was even part of gcloud and its has this apparently nigh on unique implementation of no_proxy.
# check if the host ends with any of the DNS suffixesfornameinno_proxy.split(','):
name=name.strip()
ifname:
name=name.lstrip('.') # ignore leading dotsname=name.lower()
ifhostonly==nameorhost==name:
returnTruename='.'+nameifhostonly.endswith(name) orhost.endswith(name):
returnTrue
I have read issue #700 and read the argument the ucrrent implementation is "more flexible". Having been burnt with this just recently I would argue the inconsistency is worse.
If you use a black box application that includes requests and then adds websocket support using this library things go horribly wrong. I eventually traced the issues to the nigh on unique approach websockets takes to handling no_proxy.
Appreciate its inconsistent please read https://about.gitlab.com/blog/2021/01/27/we-need-to-talk-no-proxy/ for more on the issues.
Please read the "lowest common denominator" which unfortunately the websocket-client does not meet. I was religously following this.
Googles gcloud supports proxies and I had been using it for years with no_proxy with domains with no ".". All was well until 2 weeks ago when i started using a new feature for tunnelling that uses this client. This was the only feature that did not work. It took me debugging the gcloud to eventually work out this library was even part of gcloud and its has this apparently nigh on unique implementation of no_proxy.
I would expect this to simply be consistent with all other python implementations it is currently consistent with curl but not wget. So consistent with urllib https://github.com/python/cpython/blob/030a713183084594659aefd77b76fe30178e23c8/Lib/urllib/request.py#L2548
vs
websocket-client/websocket/_url.py
Line 126 in a394b46
instead the "." should be removed and checks done against endwith for consistencies sake.
The text was updated successfully, but these errors were encountered: