Re: Proxy support

[Dan Winship <danw gnome org>]

On 10/19/2010 05:51 AM, Josselin Mouette wrote:
> I’m starting to wonder whether it makes any sense to keep using such a
> piece of software. Especially, if the proxy resolver was in libsoup
> itself, it wouldn’t need to reinvent HTTP but could use the correct
> implementation that we already have.

We're in the process of pushing proxy support down into glib. As of
2.26, glib has basic proxy support, via an extension point which is
implemented by the glib-networking module, which uses libproxy in
roughly the same way libsoup does. (As of GNOME 2.32, libsoup hasn't
been rewritten to fully use GProxyResolver rather than libproxy directly
though.)

However, glib could also make use of an extension point to allow libsoup
to implement the PAC bits of proxy lookup.

> A correct implementation would lie in libsoup-gnome itself and:
>       * directly read configuration settings using GConf (or now
>         GSettings),

FTR, libproxy used to read directly from GConf, but this caused crashes
when it was used from multithreaded programs, because libgconf isn't
thread-safe. It is possible to work around this, but it sucks (see
soup-proxy-resolver-gnome.c). GSettings should not have that problem though.

>       * provide an extension point for parsing the JS in proxy.pac
>         files,
>       * ship such an extension along with libwebkit.

Shipping extension points with non-GNOME modules is tricky, because it
potentially requires the external module to release in sync with the
GNOME release. Of course, WebKitGTK already pretty much does. (But
there's no way that would work for a mozjs-based extension, which I
think would still be desired, since in GNOME 3 the core desktop will
require mozjs.)

> What do you think? Are there any ongoing evolutions of libsoup to
> improve this situation?

I definitely agree that libproxy has major issues, and I'd be happy to
see us drop it as well (or to see it get fixed). But I'm not currently
working on that and I don't know of anyone else who is either.

(I have thought about adding a second GProxyResolver implementation,
that only does environment variable and GSettings lookup, and doesn't
handle PAC or WPAD, and having that be available for people who don't
want the libproxy dep.)

-- Dan