Bug 291316 – [WPE][GTK] Add API to configure proxy autoconfig

• Component: WebKitGTK
• Status: NEW

[Milan Crha]

Similar to bug #258728, except I'd need a C API for it, for both

   webkit_network_session_set_proxy_settings()

and 

   webkit_website_data_manager_set_network_proxy_settings().

The proxy autoconfig (PAC) is supported internally, you only did not expose it to the API users, thus it's still close to not being implemented.

A way of:

    webkit_network_proxy_settings_add_proxy_for_scheme (proxy_settings, "pac", autoconfigURL);

with

    webkit_network_session_set_proxy_settings (network_session, WEBKIT_NETWORK_PROXY_MODE_AUTO, proxy_settings);
    webkit_website_data_manager_set_network_proxy_settings (data_manager, WEBKIT_NETWORK_PROXY_MODE_AUTO, proxy_settings);

would be sufficient, if you do not want to add a  new API to special-case the autoconfig/PAC setting.

[Milan Crha]

For a reference, this comes from a user request:
https://gitlab.gnome.org/GNOME/evolution/-/issues/3028

[Michael Catanzaro]

> webkit_network_proxy_settings_add_proxy_for_scheme (proxy_settings, "pac", autoconfigURL);

No, this is too confusing! Let's just add a new function to allow specifying the autoconfig URL. I see all the plumbing already exists, so this should be not much work.

(Of course most users will never need this: it only matters if you want to use PAC for WebKitGTK but not for the rest of your desktop, which would be unusual. WebKitGTK will use your desktop's proxy settings automatically.)

[Milan Crha]

Right, all the internals are there, only the public API is missing.

I think the reporter of the downstream bug (comment #1) wanted the proxy to be used only by the Evolution, due to accessing some server-side internal things over proxy, which the whole desktop does not need to know about.

(In reply to Milan Crha from comment #3)
> Right, all the internals are there, only the public API is missing.
> 
> I think the reporter of the downstream bug (comment #1) wanted the proxy to
> be used only by the Evolution, due to accessing some server-side internal
> things over proxy, which the whole desktop does not need to know about.

Yes, pretty much that. Also, as is now, there is just silent failure when choosing Automatic in Evolution which just confuses users.
When there is a patch for webkit-2.46.x I can test it.

For now  will try to hardcode proxy:
```
--- /var/tmp/portage/net-libs/webkit-gtk-2.46.5-r410/work/webkitgtk-2.46.5/Source/JavaScriptCore/inspector/remote/glib/RemoteInspectorServer.cpp.org	2025-04-15 15:22:19.462653037 +0200
+++ /var/tmp/portage/net-libs/webkit-gtk-2.46.5-r410/work/webkitgtk-2.46.5/Source/JavaScriptCore/inspector/remote/glib/RemoteInspectorServer.cpp	2025-04-15 15:23:54.085505212 +0200
@@ -93,6 +93,10 @@
             for (unsigned i = 0; i < ignoreAddressListLength; ++i)
                 capabilities.proxy->ignoreAddressList.append(String::fromUTF8(reinterpret_cast<char**>(ignoreAddressArray.get())[i]));
         }
+    } else {
+         capabilities.proxy = RemoteInspector::Client::SessionCapabilities::Proxy();
+         capabilities.proxy->type = String::fromUTF8("pac");
+         capabilities.proxy->autoconfigURL = String::fromUTF8("http://proxyconf.infinera.com/proxy.pac");
     }
 
     return capabilities;
```
but this bites me:
```
if (capabilities.proxy->type == "pac"_s) {...
```
What should I set proxy-type to above for this if to be true?

[Michael Catanzaro]

String::fromUTF8("pac") is fine, or just "pac"_s would be shorter. They are equivalent. Is it really not matching?

(In reply to Michael Catanzaro from comment #6)
> String::fromUTF8("pac") is fine, or just "pac"_s would be shorter. They are
> equivalent. Is it really not matching?

It is matching, it is just my bad c++ skills and the time it takes to build/test webkit
My hack is working now but I would really appreciate if you could add this proxy api soon so that Evolution can
start fixing their end too.

[Michael Catanzaro]

I will try and see if there are any unexpected obstacles.

(In reply to Michael Catanzaro from comment #8)
> I will try and see if there are any unexpected obstacles.

Any luck?

[Michael Catanzaro]

Still on my to-do list, sorry.

[Michael Catanzaro]

Should have time for this next week.

[Michael Catanzaro]

Pull request: https://github.com/WebKit/WebKit/pull/45339

[Michael Catanzaro]

Well, unfortunately it looks like proxy autoconfig is broken on the CI bots, for unknown reasons. It works fine for me locally. That makes this drastically more difficult.

[Michael Catanzaro]

OK, so there's actually two problems here:

(1) Doesn't work on CI. I anticipated that the CI bots might not have glib-pacrunner, which is why I added webkit_network_proxy_settings_get_is_proxy_autoconfig_supported(). But I did not anticipate that it might exist but not work. I have a guess: the CI bot uses an old pre-0.5 version of libproxy, and it's missing the PAC extension. `webkit_network_proxy_settings_get_is_proxy_autoconfig_supported()` needs to be able to detect this, but it won't be easy because we have to pass the PAC configuration as a URL, so I guess that means creating a dummy PAC file under /tmp, passing a file URL, and then deleting the file afterwards. This is getting pretty messy; sure would be nice if the pacrunner had a self-check function.
 
(2) More importantly, it doesn't work under Flatpak because it relies on WebKitAutoconfigProxyResolver, which is just going to fail to talk to glib-pacrunner because it doesn't have unfiltered access to the host session bus. Outright replacing the default GProxyResolver is just not going to work, at least not if we use anything other than the proxy resolver portal. But the portal does not support proxy autoconfig.

Problem (2) doesn't really matter for the purposes of WebDriver, because nobody uses WebDriver under flatpak, but it's surely a blocker for adding public WebKit API; we shouldn't add API that's not going to work in practice. So I have marked the pull request as Draft. It is going to require considerable additional work (which I don't have more time for now, sorry).

I see two possible paths forward:

Path 1: WebKit implements its own pacrunner

 * WebKitAutoconfigProxyResolver should just outright ignore the system pacrunner
 * Copy pacutils.h from libproxy, and feed it into an isolated JSC VM
 * Profit

No need to talk to any host services, no need for an `_is_proxy_autoconfig_supported()` public API function, we already have our own JavaScript engine so no need to depend on Duktape. But this is also pretty heavy, and is no help at all for anything other than WebKit itself.

Path 2: Enhance proxy resolver portal

 * Add pacrunner functionality to the proxy resolver portal
 * WebKitAutoconfigProxyResolver uses the portal instead of glib-pacrunner
 * Profit

This is probably the better way, but new portal APIs require consensus.

Either way, WebKit should no longer directly depend on glib-pacrunner.

I'd say the future of glib-pacrunner is in doubt. It should not continue to exist in its current form, unsafely resetting environment variables and just hoping libproxy does what we want it to do. Clearly the pacrunner service might as well use libproxy, since libproxy already has PAC support. The missing piece in libproxy is PAC library API, so that a pacrunner can be directly implemented without resorting to environment variable shenanigans. Alternatively, libproxy could simply provide the pacrunner itself... and even the proxy resolver portal backend, because why not! This might actually be the best solution.

Very few people care about proxy support nowadays, and PAC even fewer, so proxy-related bug reports have a tendency to languish. But the libproxy developers do care, so arguably it makes sense to push as much into libproxy as possible if only for the social reason that proxy-related bug reports will have a better time in that issue tracker. CC: Jan-Michael for opinions

(We could even go further and outright remove *all* the GNOME proxy stuff from glib-networking, not just glib-pacrunner, and have glib-networking just always depend on libproxy. There's no need to do that, but also probably not any big disadvantage.) (We could also go truly crazy and have libproxy itself provide the GIO extension point, and truly delete all proxy support from glib-networking, but that would probably be pushing the layer too far.)

[Michael Catanzaro]

> I have a guess: the CI bot uses an old pre-0.5 version of libproxy, and it's missing the PAC extension.

(Well, there used to be multiple PAC extensions. Distros would subpackage them as libproxy-webkit-foo/whatever, libproxy-mozjs/libproxy-mozilla, etc. As long as of libproxy's PAC extensions is installed, it ought to work. Probably WebKit's CI bots have none. But I'm just guessing; the problem could be something different entirely.)

Hi

Thanks for working on this!

I am a bit confused w.r.t flatpak. Is this different from existing proxy support? Does that work on flatpak?

In any case, I would appreciate if this could be merged under build option so it can be used on non flatpak installs.

[Michael Catanzaro]

No, I will not add new API that doesn't work properly under Flatpak.

(In reply to joakim.tjernlund from comment #16)
> I am a bit confused w.r.t flatpak. Is this different from existing proxy
> support? Does that work on flatpak?

Existing proxy support works fine under Flatpak. Configuring a custom proxy autoconfig URL is just not something we can do without changes in the portals.