Component
Python SDK
Describe the Feature Request
When Config.proxy (or proxy_mounts) points at a socks5:// proxy, the SDK always resolves the Infrahub server's hostname remotely, on the proxy host. This is because httpx's built-in SOCKS support (httpcore.SOCKSProxy + socksio) always forwards the raw hostname to the proxy in the SOCKS5 CONNECT request — it never resolves locally first, and it does not distinguish socks5:// from socks5h:// (both behave like socks5h). There is no equivalent of PySocks' rdns flag (which requests[socks] exposes, and which curl exposes via the socks5/socks5h scheme convention).
Requesting a config option (e.g. rdns: bool on proxy/proxy_mounts) that makes the SDK resolve the Infrahub server hostname locally before connecting through the SOCKS5 proxy.
Describe the Use Case
I access an Infrahub instance through a SOCKS5 proxy. The proxy host cannot resolve the hostname the way my local resolver can (e.g. split-horizon DNS / internal-only DNS records), so remote resolution on the proxy fails or resolves incorrectly. requests[socks] handles this today via PySocks' rdns=False; the Infrahub SDK has no equivalent, and it isn't something the SDK can fix by just passing a different proxy URL scheme, since httpx/httpcore ignore that distinction internally.
Additional Information
- Confirmed in
httpcore's _sync/socks_proxy.py / _async/socks_proxy.py: the destination host string is passed as-is to socksio.socks5.SOCKS5CommandRequest.from_address(...), with no local resolution step.
- Related upstream discussions:
encode/httpx#2811, encode/httpx#2812, encode/httpcore#673.
- Workaround today: the SDK's
Config.requester/sync_requester hook can fully bypass _build_proxy_config() — a custom requester built on httpx-socks (which wraps python-socks, and implements rdns correctly) can get local resolution for normal GraphQL requests right now.
- Gap in that workaround:
_request_multipart (file/artifact uploads, both sync and async) builds its own httpx.Client/AsyncClient directly from _build_proxy_config() rather than going through the requester hook, so uploads through a SOCKS5 proxy would still resolve remotely even with the workaround in place.
- A real fix would likely mean building the SOCKS5 transport via
httpx-socks/python-socks instead of httpx's native SOCKS support when local resolution is requested, since httpx itself has no way to do this — that implies a new optional dependency, which I know is an "ask first" item for this repo.
Component
Python SDK
Describe the Feature Request
When
Config.proxy(orproxy_mounts) points at asocks5://proxy, the SDK always resolves the Infrahub server's hostname remotely, on the proxy host. This is becausehttpx's built-in SOCKS support (httpcore.SOCKSProxy+socksio) always forwards the raw hostname to the proxy in the SOCKS5CONNECTrequest — it never resolves locally first, and it does not distinguishsocks5://fromsocks5h://(both behave likesocks5h). There is no equivalent of PySocks'rdnsflag (whichrequests[socks]exposes, and whichcurlexposes via thesocks5/socks5hscheme convention).Requesting a config option (e.g.
rdns: boolonproxy/proxy_mounts) that makes the SDK resolve the Infrahub server hostname locally before connecting through the SOCKS5 proxy.Describe the Use Case
I access an Infrahub instance through a SOCKS5 proxy. The proxy host cannot resolve the hostname the way my local resolver can (e.g. split-horizon DNS / internal-only DNS records), so remote resolution on the proxy fails or resolves incorrectly.
requests[socks]handles this today via PySocks'rdns=False; the Infrahub SDK has no equivalent, and it isn't something the SDK can fix by just passing a different proxy URL scheme, sincehttpx/httpcoreignore that distinction internally.Additional Information
httpcore's_sync/socks_proxy.py/_async/socks_proxy.py: the destination host string is passed as-is tosocksio.socks5.SOCKS5CommandRequest.from_address(...), with no local resolution step.encode/httpx#2811,encode/httpx#2812,encode/httpcore#673.Config.requester/sync_requesterhook can fully bypass_build_proxy_config()— a custom requester built onhttpx-socks(which wrapspython-socks, and implementsrdnscorrectly) can get local resolution for normal GraphQL requests right now._request_multipart(file/artifact uploads, both sync and async) builds its ownhttpx.Client/AsyncClientdirectly from_build_proxy_config()rather than going through the requester hook, so uploads through a SOCKS5 proxy would still resolve remotely even with the workaround in place.httpx-socks/python-socksinstead of httpx's native SOCKS support when local resolution is requested, since httpx itself has no way to do this — that implies a new optional dependency, which I know is an "ask first" item for this repo.