After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 792153 - Cannot use proxy-resolver on a GSocketConnectable with GNetworkMonitor
Cannot use proxy-resolver on a GSocketConnectable with GNetworkMonitor
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: gio
2.54.x
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on: 791334
Blocks: 791280
 
 
Reported: 2018-01-03 08:43 UTC by Milan Crha
Modified: 2018-05-24 20:07 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed patch (16.22 KB, patch)
2018-01-09 19:00 UTC, Milan Crha
reviewed Details | Review

Description Milan Crha 2018-01-03 08:43:25 UTC
From bug #791334 comment #3:

> Looks like we might need to add a GNetworkMonitorBase:proxy-resolver property,
> which sets that proxy resolver on the proxy enumerator coming from
> g_socket_connectable_proxy_enumerate() in can_reach().

and bug #791334 comment #6:

> Milan, if you want to come up with a patch to fix your other issue about
> custom proxy resolvers not being usable with GNetworkMonitor, please file
> a separate bug report and attach it there (let's keep one bug report per
> issue). I'll be happy to review it. Thanks.

I do not have any patch for it, but I know that using proxy-resolver directly on a GNetworkMonitor is a wrong idea, because the default GNetworkMonitor instance can be used in multiple threads at the same time, while each thread (thus also GSocketConnectable) can require different (or no) proxy.

That means that the right change is to allow proxy-resolver on the GSocketConnectable, rather than on GNetworkMonitor.
Comment 1 Milan Crha 2018-01-09 19:00:45 UTC
Created attachment 366574 [details] [review]
proposed patch

This is the change which makes it work for me, but we can discuss the approach being used as such too, if you think it's not the glib way.

I added a "proxy-resolver" property to the GSocketConnectable interface, thus any implementation of it should override that property. Once it's set, it's also propagated further in the name resolution/enumeration and so on.

I didn't want to change API/ABI, thus the semi-awkward change in GSocketAddress.
Comment 2 Philip Withnall 2018-01-19 12:37:16 UTC
Review of attachment 366574 [details] [review]:

It seems a bit wrong to me to add a GProxyResolver (which describes a mechanism of how to connect to something) to all the G*Address objects (which describe the address of something). Addressing and mechanism should probably not be conflated in the same object.

Could we instead add a new GNetworkMonitor method which is like can_reach() (and can_reach_[async|finish]()) but which additionally takes a GProxyResolver argument? Then the mechanism (GProxyResolver) stays with the GNetworkMonitor, but can differ between threads/requests to the network monitor.
Comment 3 Philip Withnall 2018-01-19 12:38:33 UTC
Dan, do you have any thoughts here?
Comment 4 Dan Winship 2018-02-06 14:47:42 UTC
Agree that this belongs on GNetworkMonitor somewhere, not on G*Address.

(Not sure g_network_monitor_can_reach_with_proxy_resolver() is the right answer... I might have suggested g_network_monitor_new_with_proxy_resolver() or something instead?)
Comment 5 GNOME Infrastructure Team 2018-05-24 20:07:08 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/1320.