A user of my OpenMeteo binding filled an issue asking for proxy support when connecting to the online service and I replied that because I use HttpUtil.downloadData then everything should be handled because it reads system properties like http.proxyHost and http.proxyPort.
The first issue I had answering this is that I have no idea where those are configurable in MainUI
And the second issue is that while there is a http.nonProxyHosts system property, the user would really prefer to have an “include list” for hosts that must be proxyied. Is this at all possible?
I doubt they are configurable in MainUI. Those are most likely settings that apply to the whole JVM, that must/should be set as start arguments to the JVM itself.
Perhaps it would work to simply set those as environment variables before starting OH, it depends on the details of how this works on Java’s side.
I doubt that you will find a way to do this through the UI, and I also doubt that you’ll find a “proxy include list”. Normally, proxies are applied universally, so that all traffic go through them. The exception list probably exists because some services just won’t work with a proxy.
I would question what the user is trying to achieve. A proxy is primarily meant as a cache that limits unnecessary external calls, and used to be much more relevant (and widely used) back when connections were much slower. It sounds like the user is trying to achieve something else, some form of anonymization of spoofing or similar. I’m not sure using a proxy like that is a viable path.
You shouldn’t modify the binding so that it can set these properties, because they should not be changed while the JVM is running. As with all system properties, changing them isn’t thread-safe, and will affect all kind of other things so that the implications are impossible to predict.
If there is some special need for this binding, you could manually control proxy for the binding specifically:
It would indeed be nice, but in the meantime, thanks for pointing out that executeUrl method, it’s a good candidate as it already existed in OH4 for which I have to keep compatibility
That sounds like a dirty workaround for a network problem to me. There’s no reason why a proxy, or a tunnel like here, would work better than a direct connection, unless is “tunnels through” network problems that would otherwise disrupt parts of the communication. Normally, all kind of proxy use just adds problem, and a direct connection is the most stable, straight forward solution.
That’s why I asked if there was a special need for this binding. If “all” bindings need to, it wouldn’t make sense, but as I said before, proxy isn’t used much these days, and if it’s used, you typically apply it to all traffic.
This use case, is a workaround for another problem, which is why it doesn’t exist in HttpUtil, and why Java itself has no “whitelist” for destinations that should be proxied.
I don’t know the user’s setup, but if this was me, and there was a “genuine need” (as opposed to a workaound for another problem), I would use the firewall to route traffic from a certain address (OH) to certain addresses (API endpoints) through a tunnel or through a different route etc.