Bug 222374
| Summary: | [GTK] Consider adding support for socks5h:// proxying | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Haelwenn (lanodan) Monnier <contact+bugs.webkit.org> |
| Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | bugs-noreply, cgarcia, mcatanzaro, pgriffis |
| Priority: | P2 | ||
| Version: | WebKit Local Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Haelwenn (lanodan) Monnier
Currently WebKitGTK (probably because of one library in the libsoup/glib-networking/libproxy stack) doesn't have support for socks5h, which means that DNS resolving through SOCKS isn't supported, which prevents usage of things like Tor to work properly (there is workarounds but I wouldn't really depend on that).
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Carlos Garcia Campos
Yes, we simply pass a GProxyResolver to libsoup, so it's in gli/glib-networking where the support should be added. I guess there's not much we can do in WebKit.
Michael Catanzaro
GProxyResolver isn't designed to handle DNS, though. You might be looking at a total rethink of the boundaries between GResolver and GProxyResolver? I'm not sure.
Certainly this needs to be addressed at the glib level. libsoup and WebKit are much higher-level.
(Mildly-related: if you care about proxies, nobody knows how they are supposed to work: https://gitlab.gnome.org/GNOME/glib/-/issues/2291.)
Haelwenn (lanodan) Monnier
Thanks for the mildly-related issue.
At least in the case of socks, specially with introducing the socks5h/non-socks5h distinction it should be non-ambiguous.
And with using `http_proxy`, `HTTPS_PROXY`, `${PROTOCOL}_PROXY` and `ALL_PROXY` like is done in `curl`'s environment variables (btw that's the way I'm doing it for everything as a non-DE user) might help even further on this.