-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possibly no connect support? #268
Comments
I will try to reproduce this problem when I have access to a Windows machine |
Ok, I have written a small Python script to imitate the situation I'm in. The gist is here: https://gist.github.com/Groovin-Dev/634ebf9b7069e6ec4d6223d979e418b7 Running this script without the proxy allows it to print everything and get to the WebSocket messages. Running with the proxy will cause it to fail when it makes the CONNECT request |
I still haven't test the Wiindows yet but I took some time to test the python script you provide and bring some minor changes and fixes to the library. First request:gateway_status = make_http_request('http://127.0.0.1:9999/v1/gateway')
if gateway_status != 200:
sys.exit(1) No problem here. Second request:connect_status = make_http_request('http://127.0.0.1:9999/connect', 'CONNECT')
if connect_status != 200:
sys.exit(1) The CONNECT method is also used to establish a tunnel through a proxy. When this request lands, we must figure out if the client wants a tunnel to the host or send a CONNECT request to the host in plain HTTP. Here we added a fix that detects if the request_path in an absolute URI and treats the CONNECT method like any other HTTP method. Third requestrpc_status = make_http_request('http://127.0.0.1:9999/v1/rpc?gateway=1')
if rpc_status != 101:
sys.exit(1) Makes flask produce this answer:
Even if you can put an explicit status code and a response body in flask, this is not a common HTTP flow and most client will not expect reading a response body. Moreover, there's no hint that tells the client in what protocol the server wants to switch to (no Upgrade header). You will notice that this request will fail under curl. Fourth request make_websocket_request() There is a fix we set to proceed correctly websocket over plain text #274 |
Describe the bug
I'm not 100% sure what the issue is and I'm really not the best with networking but I believe there is an issue with the CONNECT method.
When using
Fluxzy.Core
andFluxzy.Desktop
(1.26.2-alpha) there is an application that will fail to load because it gets stuck in a loop of getting the gateways (the repeated requests are from the server trying again not Fluxzy)Describe the tool and the environment
Fluxzy.Core
andFluxzy.Desktop
(1.26.2-alpha)To Reproduce
Steps to reproduce the behavior:
Predecessor
(I'm not 100% sure how to remake this)Fluxzy.Desktop
with a filter looking for any URL containing "omeda"Screenshot
Expected behavior
The requests should go though as normal. In this case, 2 CONNECT requests followed by 2 GET requests that then upgrade to WS
Additional context
The WS fix in
1.26.2-alpha
did work for testing onecho.websocket.org/.ws
but does not seem to help with this issue.I'm not the best at this so if you would like any more info please let me know and I'll do the best I can to get it for you.
Also, Omeda (the devs of Predecessor) are aware of my actions using a proxy on their game and have allowed it just in case you were worried about that
The text was updated successfully, but these errors were encountered: