GNOME Bugzilla – Bug 659857
Handle PAC and WPAD within glib-networking
Last modified: 2018-05-29 06:44:47 UTC
Currently libproxy is required in order to have WPAD and proxy.pac support. However this library is extremely buggy and implements in itself a broken HTTP parser. We should only keep one working HTTP implementation, therefore I suggest to: - rip off the interesting bits from libproxy 0.3 (WPAD support and proxy.pac resolving) into glib-networking - rely on libsoup for all HTTP support - use directly JScore now that it has been split in a separate library from webkit If developers agree with this approach I can work on it, although I don’t promise much since I don’t have a lot of spare time.
Yes please We may possibly want to have the JS interpreter be another extension point... it would be lame-ish for gnome-shell to have to use JScore to interpret PAC files.
If the JS interpreter remains in an external process - and there are several good reasons for that - is that still a real issue? It becomes replaceable.
ah, true WPAD should also make use of NetworkManager. You can query it over D-Bus to get the values of DHCP options, so we can do that to check if the DHCP server sent the WPAD option.
I don’t have a WPAD setup to test it, so I’ll probably start with proxy.pac. Any idea how to avoid a circular dependency with libsoup, though? Should the PAC runner be in a separate module maybe?
glib-networking isn't a build-time dependency of libsoup. oh, but it's listed that way in jhbuild, because by default, libsoup's configure will error out if glib-networking isn't installed (unless you pass --disable-tls-check). But that check can probably go away now away. People should have figured it out by now (and libsoup gives an error at runtime now too if you try to do https without having glib-networking installed).
> Currently libproxy is required in order to have WPAD and proxy.pac support. > However this library is extremely buggy and implements in itself a broken HTTP > parser. If you are aware of bugs in libproxy, file it please. Assuming it's extremely buggy is unhelpful. The HTTP parser is indeed very limited, but no bug ever been reported yet. > > We should only keep one working HTTP implementation, therefore I suggest to: > - rip off the interesting bits from libproxy 0.3 (WPAD support and proxy.pac > resolving) into glib-networking > - rely on libsoup for all HTTP support > - use directly JScore now that it has been split in a separate library from > webkit Bringing stuff from libproxy to glib-networking was and is still a very bad idea. It breaks all the effort that has been done so far to make application cross DE in regard to proxy settings. Until the settings get placed somewhere it make more sense (e.g. NetworkManager connections information), we should stick with libproxy as much as possible. 0.4.7 do support Gnome 3, and do use the split JSCore library to avoid all the GTK 2/3 conflict.
(In reply to comment #6) > If you are aware of bugs in libproxy, file it please. Assuming it's extremely > buggy is unhelpful. The HTTP parser is indeed very limited, but no bug ever > been reported yet. I don’t think libproxy is a good idea, so I’m not going to help fix it. I’m afraid we’ll have to agree to disagree.
(In reply to comment #7) > I don’t think libproxy is a good idea, so I’m not going to help fix it. I’m > afraid we’ll have to agree to disagree. I'm not here to do a like/don't like war, it's unhelpful to our users. I'm defending one of the freedesktop goals, and Telpathy goal too, which is to have softwares that works seamlessly between desktops. I added the proxy support in Glib so Gabble and other Telepathy component does not have to care much about proxy configuration and which desktop or platform we are running on while being able to use a GObject friendly library. With recent development and your current proposition we our going away from our goal. Libproxy was (and is still) the only library that do help supporting system proxy settings across desktop and platforms, thus the reason to choose it. It's also the only library that do dynamically choose the right configuration back-end for your active session, making it possible to run the same software on different desktop environment. This is even more important since the gnome configuration is no longer visible in KDE environment (OnlyShowIn=GNOME). Replacing software is fine, but it must be done with the current feature set in mind. Otherwise we regress. We also have to stop thinking Glib is gnome only library, it is used in many backend software and libraries which are not bound to any desktop or platforms.
(In reply to comment #8) > I'm not here to do a like/don't like war, it's unhelpful to our users. I'm > defending one of the freedesktop goals, and Telpathy goal too, which is to have > softwares that works seamlessly between desktops. That’s a laudable goal, but the road to hell is paved with good intentions. And a library that ends up reimplementing a HTTP parser and indirectly linking to half of two desktops just to access settings does it wrong. Although personally I don’t care much about this goal, let’s try to be constructive: you could put the proxy configuration in X settings, or - better - available through a common D-Bus interface with a per-desktop configuration. This way GIO (and the same goes for other libraries) would only have to load the configuration through this interface. Then write the service using the appropriate libraries (like libsoup and libmozjs/libjscore), make it configurable through a .ini-like file in .config/ (all DEs can r/w such files), and make it communicate with NM for the appropriate stuff. All the pieces are here - you already wrote some of them. There: all the ugliness is gone. All it needs is architecturing stuff correctly instead of trying to glue together pieces that were not made for that.
So, how to talk to a host via a proxy: 1. Figure out where proxy preferences might be stored 2. Read those preferences 3. If the prefs involve WPAD or PAC, handle that 4. Now you have a list of potential proxies 5. For each proxy, try to connect to it, and speak its protocol, until one succeeds. 6. Profit! libproxy defines 1-4 as its problem, and 5-6 as the application's problem. GLibProxyResolver defines 1-4 as libproxy's problem, 5 as glib's problem, and 6 as the application's problem. But as Josselin points out, libproxy is never going to be able to do #3 as well as glib-networking could, just like it could never do #5. (Actual real life example: "Why can't I put my PAC file on an https server?") So what we want is for glib to take over 3 and 4 from libproxy. libproxy can keep doing 1-2. I believe we are all in agreement on 6.
(In reply to comment #10) > 1. Figure out where proxy preferences might be stored > 2. Read those preferences > 3. If the prefs involve WPAD or PAC, handle that > 4. Now you have a list of potential proxies > 5. For each proxy, try to connect to it, and speak its protocol, > until one succeeds. > 6. Profit! I don’t think 1 is a legitimate task. If you manage to define clearly a common configuration system for all DEs - and really, it’s much, much simpler than what was done successfully for MIME - they will just have to adapt. > But as Josselin points out, libproxy is never going to be able to do #3 as well > as glib-networking could, just like it could never do #5. (Actual real life > example: "Why can't I put my PAC file on an https server?") So what we want is > for glib to take over 3 and 4 from libproxy. libproxy can keep doing 1-2. And once you have a common configuration location, 1 stops existing, and 2 can trivially be moved to glib. Until there is such a common configuration, I don’t believe there is added value in trying to read configuration from several different places.
> But as Josselin points out, libproxy is never going to be able to do #3 > as glib-networking could Libproxy is a software just like glib-networking, it's all a matter of doing it. Both can handle it perfectly, but I don't think it's the place to hide such system wide tool. A D-BUS driven PAC runner would be a great tool for everyone, regardless if they are using GLib or not. I would suggest implementing such a daemon in an independent module and make sure the D-Bus API is documented and stable. Doing out-of-process PAC is not new idea, it's been two years now that this is pending queue in the libproxy task list. But nobody actually worked on that, because most of us does not depend on proxy anymore. We need not to forget the reality, at the moment no-one have ever asked for PAC over HTTPS. PAC are generally only accessible within a private network and cannot contain passwords. WPAD is considered a security threat through DHCP or DNS, which is the reason this was never merged into libproxy. Only a stripped down (hopefully safer) approach is implemented. Keep in mind that very few application uses GIO in general, thus even if you tell people that in GIO you did it right, it's a bit futile. Even libsoup is not really using GIO. Finally, fixing proxy setting architecture may imply having to re-implement the three functions libproxy API on top of your architecture. This is what happened on Meego, and I must say that their architecture is quite good, while the project quite dead :(
(In reply to comment #11) > (In reply to comment #10) > > 1. Figure out where proxy preferences might be stored > > 2. Read those preferences > > 3. If the prefs involve WPAD or PAC, handle that > > 4. Now you have a list of potential proxies > > 5. For each proxy, try to connect to it, and speak its protocol, > > until one succeeds. > > 6. Profit! > > I don’t think 1 is a legitimate task. If you manage to define clearly a common > configuration system for all DEs - and really, it’s much, much simpler than > what was done successfully for MIME - they will just have to adapt. > Go for it, define something ! But meanwhile we have to keep that thing working as much as possible which make 1 legitimate.
(In reply to comment #11) > And once you have a common configuration location, 1 stops existing, and 2 can > trivially be moved to glib. Until there is such a common configuration, I don’t > believe there is added value in trying to read configuration from several > different places. You are of course welcome to build with --without-libproxy if you don't find that feature useful. (In reply to comment #12) > We need not to forget the reality, at the moment no-one have ever asked for > PAC > over HTTPS. Um, no, that's why I referred to it as an "actual real-life example". (I told him to file a bug but he never did.) > Keep in mind that very few application uses GIO in general Yes, but this is a gio bug, so we're only talking about the ones that do
(In reply to comment #13) > (In reply to comment #11) > > I don’t think 1 is a legitimate task. If you manage to define clearly a common > > configuration system for all DEs - and really, it’s much, much simpler than > > what was done successfully for MIME - they will just have to adapt. > > Go for it, define something ! But meanwhile we have to keep that thing working > as much as possible which make 1 legitimate. Re-read me: I am not interested in talking about cross-desktop compatibility for weeks on freedesktop lists. You are the one interested in this feature, you should be the one doing it if you want it working. It would be much more constructive to define a common D-Bus interface for a proxy manager and a common configuration file than to hack around a pile of stuff that tries to read every known configuration in the world.
Would be nice to close this bug as nothing really useful is to be done in here. As I was expected, more then 8 month later we are at the same state where libproxy is the only solution for cross DE, which tell me having both D-Conf and libproxy in glib-networking is the right thing for our users (this bug blames glib-networking btw). One may choose for certain reason to use libproxy, and other can use the direct d-conf backend if they don't need the cross DE capabilities.
I think there's benefit in handling WPAD and PAC ourselves, and I did start working on that at one point (http://git.mysterion.org/glib-networking/log/?h=pacrun)
(In reply to comment #17) > I think there's benefit in handling WPAD and PAC ourselves, and I did start > working on that at one point > (http://git.mysterion.org/glib-networking/log/?h=pacrun) Not that I'm against, but this is an empty argument, it would be nice to share with us what you think are the benefits.
-- 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/454.
Reopening. This bug was migrated to https://gitlab.gnome.org/GNOME/glib, but it should have been migrated to https://gitlab.gnome.org/GNOME/glib-networking.
-- 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-networking/issues/28.