LibProxy+LibWebview: Add System Proxy Support

[kunlinglio]

Replaces the external libproxy dependency with a new in-tree LibProxy library, adds system proxy detection (macOS currently and environment variables), and exposes proxy configuration through the browser's Settings UI.

• LibProxy: A in-tree proxy library

  • Extract ProxyData from LibCore into LibProxy.
  • Implement proxy detection logic from LibCore into a standalone library under LibProxy. Reads http_proxy/HTTP_PROXY, https_proxy/HTTPS_PROXY, and all_proxy/ALL_PROXY environment variables. And uses the System Configuration framework to read system-wide proxy settings for HTTP, HTTPS, and SOCKS5.

• Service: integrate proxy with libcurl
  Proxies detected by LibProxy are applied to HTTP requests via libcurl options.

• LibWebView: Add "Proxy Mode" option in Settings UI
  A new "Proxy Settings" element in the Network tab of about:settings, with options Use system proxy settings and No proxy (Direct).

  

• LibCore+LibWeb: Remove unused code
  Removed unused ProxyMappings from LibWeb.
  Removed proxy_data parameter from start_request IPC — proxy resolution now happens entirely server-side in RequestServer.

• Vcpkg: Dropped external libproxy dependency
  Removed the libproxy vcpkg port — it worked poorly with MSVC and didn't support Android or BSD.

[avbdr]

I think it will be great to add proxy settings reading from gsettings if running under gnome or from ~/.config/kioslaverc if running under KDE.
If would be even better if those settings would be read after they changed

[kunlinglio]

Yes, I agree that we need to support some kde or gnome specific stuff.

However, since almost every desktop environment has there own way to get proxy settings, it will be pretty a big work (we need to supports windows, gsettings, kde, xdp, and even android). I just want to get some feedback from maintainer before pushing this into a very huge pr.

[R-Goc]

On windows it looks like the relevant API would be WinHttpGetIEProxyConfigForCurrentUser from winhttp.h. Requires linking Winhttp.dll. Not sure if you have access to a machine to test or not. If not this could be done later by someone else that ahs a windows machine.

[alimpfard]

I thought the whole point of that proxy library was to query these platform-specific things?

[kunlinglio]

@alimpfard
Eh...Which proxy library do you mean? libproxy from vcpkg or the LibProxy in this pr?

[alimpfard]

sorry, I meant libproxy from vcpkg. just what I remember you saying on discord.

[kunlinglio]

Yeah.

But it's heavily rely on glib and many compiler extension of gcc&clang. It really difficult to make it works with msvc, which is our default compiler for vcpkg. (I have spent some days on it, but only find a very hacky way to patch it, which's, as expected, rejected by vcpkg...)

And there are still some reason for turning to a self-contained lib:

• It doesn't support android and other BSD system.
• It implementation is quite slow, make several syscall each request.
• If we want to support PAC, we may need to download js from network. The interface provided by libproxy is blocked, which is not very ideal for RequestServer.

[alimpfard]

so to be clear, the architecture I was suggesting before was that LibWeb would be the source of truth for these; RS should only get a ProxyData by ipc.
re libproxy (the dependency): if we're gonna pull some dep, we should not be adding extra code that does what the dependency should be doing.

[R-Goc]

What I understand from this is that libproxy(the dep) doesn't work well on windows (or maybe doesn't build) and doesn't either cache properly or is just suboptimal or both and as such the implementation from scratch. And we won't be pulling the dep.

[kunlinglio]

Yeah, that's what I means.

Current version on vcpkg doesn't work at all. It has a huge refactor and switch to Gobject/glib, making the effort on patching it might be harder than writing one from scratch (the libproxy dep has less than 4000 line of c code and many of them is just to deal with PAC and js runtime).

Re "LibWeb would be the source of truth": Oh, that's my bad. But I'm still very curious about why we allow LibWeb to determined the proxy? There are many states shared, for example, proxy cache. And Chromium handle proxy configuration in RS as well.

[alimpfard]

why allow LibWeb to determined the proxy

largely an idealised view I have that proxies should be decided at the point a request is made; that would also allow later extensions to expose this to the user, or decide based on more than just the request URI.

Chromium handles proxy configuration in RS

That would be very surprising, can you point me at where this happens? I took a brief look and it seemed like the network service was getting its proxy configuration info from the outside (wherever that pipe is connected).

[kunlinglio]

@alimpfard
Maybe we can take this discussion back to Discord? :)

[github-actions]

Your pull request has conflicts that need to be resolved before it can be reviewed and merged. Make sure to rebase your branch on top of the latest master.

[github-actions]

Your pull request has conflicts that need to be resolved before it can be reviewed and merged. Make sure to rebase your branch on top of the latest master.

[gmta]

Thank you for taking the time to work on this pull request.

As announced in "Changing How We Develop Ladybird", we are closing all currently open public pull requests as part of ending the public code contribution path for Ladybird.

This is not a judgment on the quality of your work; we are very grateful for the effort you put into this pull request. But as of right now, code changes to the Ladybird codebase will only be introduced by project maintainers.

We still welcome clear bug reports, reduced test cases, website testing, standards discussion, design discussion, security reports, and technical feedback.