nodes behind corporate firewall may not be able to reach relay port 22067; with some firewalls they may have to use a mandatory http proxy to reach web servers on http :80 or https :443, so even relay servers running on ports :80 or :443 may be unreacheable.
proposal: can we create a ârelay-protocol over httpsâ for syncthing, so that you can tunnel a ârelay-protocolâ connection over an https connection (possibily through one or more https proxy)?
this will have two advantages:
1 - we can use syncthing even where the only connection to the internet is through an https proxy;
2 - relay hosts will not require a dedicate ip:port pair (which for :443 will exclude the possibility of hosting an https web server on the same server), but could host a ârelay server over httpsâ in a sub-path of their existing web infrastructure (es: âhttps://my.host/my-web-site/stuff/other/syncthing-relayâ );
has this already been thought? your opinion?
Iâm not strong in go, but I can write a more detailed spec, and provide a client-server reference implementation, if you like the concept.
Relay connections are TLS, essentially indistinguishable from HTTPS. There are some relays on port 443, but not as many as would perhaps be optimal. It should work fine through an HTTPS or SOCKS5 proxy, I think.
HTTP is request-response, which means that the client makes a request, and the server responds. Thereâs no way for the server to send data back to the client.
This means that itâs very much unsuitable for Syncthingâs connections, as they need to push data in both directions.
Sure, you can do stuff with long polling, but youâre adding orders of magnitude of overhead. Plus your IT department is going to want to know why youâre making 1,000 requests a second, every second, all day.
Moreover some additional comments on corporate proxies, in case of tunneling over simple HTTP, some of them restrict the âconnectâ method to known servers and/or services, and most of them check for a real web page (or at least it will do a dummy âGET /â) on the target server.
well, I went ahead and did it anyway, at least I learnt something .
@calmh: relay over port 443 is good, but requires a dedicated server with port 443 available. Many people already own a private server/vm used for a personal web site etc, in this case port 443 may be already used by the web server, and thus not available for relay server. My solution may be put behind a forward proxy, server side, and work side by side with an existing web server (for example I can leave my web pages at https://personal.site and add my http-relay service at https://personal.site/http-relay/ )
@canton7: actually bidirectional data transfer over http is used by many rich javascript apps. Iâve put together a simple implementation and it works well enough⌠the http overhead is not even that much, compared to a regular tcp connection. You never make 1000req/sec, more like one long connection every 30sec or so for pulling, and one ondemand conenction for pushing. The protocol does not require realtime latency, so you can buffer data and make less http calls, for better protocol efficency.
@damajor: my impl use plain http POST, with my company firewall it works; itâs possible to add code to mimic a web page access on both client and server side, if necessary.
I add a little diagram to show my current implementation structure; the client module must be integrated in the client app to work; the server module instead is just a proxy/filter for the unmodified syncthing relay app, and integrates with the current relay network.
.