GNOME Bugzilla – Bug 691105
Allow GSocketClient to override GProxyResolver for per client proxy settings.
Last modified: 2013-02-14 22:23:34 UTC
xombrero, the web browser, uses webkit, which uses libsoup. libsoup only allows setting an http proxy via the proxy-uri object. When I asked libsoup to support SOCKS5 addresses as well, they replied with: "That would definitely make sense. The catch is that libsoup doesn't implement SOCKS itself, it just takes advantage of GSocketClient's proxy support, but there's currently no way to force GSocketClient to use a proxy other than one returned by the GProxyResolver, and there's no easy way to override GProxyResolver. So... I think step 1 would be to add an API to GSocketClient, something like g_socket_client_set_proxy(GSocketClient *, GProxy *), to override the choice of proxy. Then, given that, it wouldn't be hard to adjust SoupSession's proxy-uri code to handle socks URIs appropriately." Is this something worth adding?
Yes, I made that suggestion as the maintainer of both libsoup and of the networking code in glib. I'm just not necessarily likely to hack on it myself any time soon, so if you want to see it, you should submit a patch.
Created attachment 234752 [details] [review] GSocketConnectable: add proxy_enumerate_with_resolver() method Add g_socket_connectable_proxy_enumerate_with_resolver(), to get a GSocketConnectable to enumerate addresses using a specific proxy resolver. Since all existing connectables implement proxy_enumerate() by returning a GProxyAddressEnumerator, the easy way to do this is to add a proxy-resolver property to that. To simplify things, we let GSocketConnectable fix up the returned GProxyAddressEnumerator itself if the connectable doesn't implement the new method.
Created attachment 234753 [details] [review] GSocketClient: add proxy-resolver property Add a proxy-resolver property to GSocketClient, to allow overriding proxy resolution in situations where you need to force a particular proxy rather than using the system defaults.
Created attachment 234754 [details] [review] GSimpleProxyResolver: new simple GProxyResolver class Add GSimpleProxyResolver, for letting people do static proxy resolution, and to use as a base class for other resolvers (such as GProxyResolverGnome).
(In reply to comment #4) > Add GSimpleProxyResolver, for letting people do static proxy > resolution, and to use as a base class for other resolvers (such as > GProxyResolverGnome). Most of the code here (and in particular, all of the ignore-hosts handling) came from GProxyResolverGnome, and there'll be a followup patch at some point to port GProxyResolverGnome to be a subclass of GSimpleProxyResolver.
Created attachment 235151 [details] [review] GSocketClient: add proxy-resolver property new version that doesn't add a new GSocketConnectable method for now, but just implements it all internally (since there may be other GSocketConnectable changes coming up, so it would be good to think about them all together).
Created attachment 235152 [details] [review] GSimpleProxyResolver: new simple GProxyResolver class Add GSimpleProxyResolver, for letting people do static proxy resolution, and to use as a base class for other resolvers (such as GProxyResolverGnome).
Nicolas: would be good to get your opinion on these patches...
Review of attachment 235152 [details] [review]: I fully agree with this class. It's a great tool.
Review of attachment 235151 [details] [review]: First thought was, why not using the same pattern as GResolver (the DNS resolver), which has a method called g_resolver_set_default (would be g_proxy_resolver_set_default()) ? On the other side, this way allow for having different proxy for different connections, which is not possible with the GResolver approach. I guess there is some reflection needed if we want simplicity and consistency, or flexibility. What I think, is that this complex case can always be implemented by manually resolving proxies (using the resolver of your choice, or using directly your own GProxy instance). g_proxy_resolver_set_default() Would appear more like an application setup which you don't need to care about for each connection.
(In reply to comment #11) > On the other side, this way allow for having different proxy for different > connections, which is not possible with the GResolver approach. Yeah. I think I remember you talking about a case where you always wanted to use a particular SOCKS proxy when talking to a particular XMPP server, regardless of the rest of the system proxy config. This could implement things like that. > What I think, is that this complex case can always be implemented by manually > resolving proxies (using the resolver of your choice, or using directly your > own GProxy instance). That was my first thought too, but the problem is, GSocketClient really does quite a lot of useful work, and you don't want to have to reimplement that by hand...
(In reply to comment #12) > (In reply to comment #11) > > On the other side, this way allow for having different proxy for different > > connections, which is not possible with the GResolver approach. > > Yeah. I think I remember you talking about a case where you always wanted to > use a particular SOCKS proxy when talking to a particular XMPP server, > regardless of the rest of the system proxy config. This could implement things > like that. For the reference: http://cgit.collabora.com/git/user/nicolas/wocky.git/commit/?h=wocky-s5b&id=cadcb5348da596244255ef878811734a54a34ab0 In XMPP there is a file transfer mode, where SOCKS5 protocol (non standard server) is used. So what I do is establish the connection and then do the socks5 handshake using the GProxy. This case cannot be simplified as the first connection can and should use the default proxy configuration. > > > What I think, is that this complex case can always be implemented by manually > > resolving proxies (using the resolver of your choice, or using directly your > > own GProxy instance). > > That was my first thought too, but the problem is, GSocketClient really does > quite a lot of useful work, and you don't want to have to reimplement that by > hand... In general I agree with your solution, it's simply better. But maybe we should poke around to see what others think of it. I just wanted to make sure the this smll inconsistency is not unseen.
(In reply to comment #13) > This case cannot be simplified as the first > connection can and should use the default proxy configuration. But you're creating a new GSocketClient for every connection, so if you had g_socket_client_set_proxy_resolver(), you could call that on the connections where you want to override the proxy, and not on the ones where you don't. > But maybe we should > poke around to see what others think of it. I'm not sure there's anyone else who knows those bits of gio well enough to have strong opinions about the right and wrong way to implement this.
(In reply to comment #14) > (In reply to comment #13) > > This case cannot be simplified as the first > > connection can and should use the default proxy configuration. > > But you're creating a new GSocketClient for every connection, so if you had > g_socket_client_set_proxy_resolver(), you could call that on the connections > where you want to override the proxy, and not on the ones where you don't. Well that case is different, it does not override the proxy, it adds one more proxy on top. > > > But maybe we should > > poke around to see what others think of it. > > I'm not sure there's anyone else who knows those bits of gio well enough to > have strong opinions about the right and wrong way to implement this. Fair, in any case, it would still be possible to introduce g_proxy_resolver_set_default() if someone was to request it.
Review of attachment 235151 [details] [review]: Let's do it this way ;-)
Attachment 235151 [details] pushed as 7c49869 - GSocketClient: add proxy-resolver property Attachment 235152 [details] pushed as ee17a54 - GSimpleProxyResolver: new simple GProxyResolver class