[Do not merge] Add DeltaSharingClient Proxy Configuration

[zhu-tom]

No description provided.

[elghali97]

Nice thanks for the PR @zhu-tom !

[moderakh]

@zhu-tom The change looks good to me as a custom modification to support proxy usage when interacting with the server. However, please do not merge the PR.

Thank you

[bob-hodgeman-kr]

Upon testing this PR, I found that I was unable to make an https call via an http proxy. I've tested the proposed fix and basic testing shows that it is working.

[bob-hodgeman-kr]

This constructor always constructs an insecure (http) route through the proxy. This does not work if one is using an http proxy to make an https call to the server. Instead, consider using an alternate constructor and setting the secure flag appropriately based on the target:

Suggested change

	new HttpRoute(target, proxy)
	val isSecure = target.getSchemeName == "https"
	new HttpRoute(target, null, proxy, isSecure)

[sevann71]

Hi team,
Do you know when this fix will be merged?
Thanks a lot

[GhaileneSouissi]

Hi team 👋

Is there any update on why this PR can’t be merged? In many enterprise setups all egress must go through an HTTP(S) proxy, and the current Scala client builds an HttpClient without useSystemProperties() / a system route planner. As a result it ignores standard JVM proxy flags (-Dhttp.proxyHost, -Dhttps.proxyHost, http.nonProxyHosts, etc.), which makes the client unusable behind corporate proxies unless the network provides a fully transparent proxy.

Would you consider a minimal, backward-compatible change to the client builder (e.g., calling useSystemProperties() or wiring a SystemDefaultRoutePlanner)? That would let the client honor existing JVM/env proxy configuration while keeping custom configs possible.

If merging isn’t feasible, could you share the rationale (security/perf concerns, API stability, or platform compatibility)? I’m happy to help with tests and a small doc snippet.

In the meantime, how can we use the library without this proxy configuration?