Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upFix a websocket connection issue when running in the proxy mode #2089
Conversation
Steps to reproduce: 1. Run Zeronet with --ui_trans_proxy in a docker container or other isolated environment. 2. Set 127.0.0.1:43110 as a HTTP Proxy in a browser. 3. Navigate to http://talk.zeronetwork.bit/ 4. The site stops loading, since the websocket connection isn't functional. The bug consists of 2 related issues: 1. Connect to the proper address. When running in the proxy mode, Zeronet sends its env["SERVER_NAME"] and env["SERVER_PORT"] as the websocket destination address in the wrappper HTML code (variable `server_url`). That looks wrong for me, since the values of those variables have nothing to do with the actual address accessible by the browser. ZeroNet can run in a container, the connection also can be tunneled over SSH and so on. In all those cases, the internal SERVER_NAME makes no sense as the destination at all. The code for sending and handling `server_url` is deleted. The browser should connect to the websocket in the same way as it connects to the ZeroNet UI in general. 2. Send the proper response for CONNECT requests. A browser tries to connect to the correct address, but it still fails. A browser, when connecting via a HTTP proxy to a webdocket, uses the [HTTP tunneling protocol](https://en.wikipedia.org/wiki/HTTP_tunnel), and ZeroNet lacks support for it. To fix this, it's enoght to send the "200 OK" response on the CONNECT method request.
|
We still have some bugs here.
And allows what it shouldn't:
But this should be fixed in a different pull request, I guess, as it affects other parts of |
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.
Steps to reproduce:
The bug consists of 2 related issues:
Connect to the proper address.
When running in the proxy mode, Zeronet sends its env["SERVER_NAME"] and env["SERVER_PORT"] as the websocket destination address in the wrappper HTML code (variable
server_url). That looks wrong for me, since the values of those variables have nothing to do with the actual address accessible by the browser. ZeroNet can run in a container, the connection also can be tunneled over SSH and so on. In all those cases, the internal SERVER_NAME makes no sense as the destination at all.The code for sending and handling
server_urlis deleted. The browser should connect to the websocket in the same way as it connects to the ZeroNet UI in general.Send the proper response for CONNECT requests.
A browser tries to connect to the correct address, but it still fails. A browser, when connecting via a HTTP proxy to a webdocket, uses the HTTP tunneling protocol, and ZeroNet lacks support for it. To fix this, it's enoght to send the "200 OK" response on the CONNECT method request.