On Dec 21, 2007 5:32 AM, Daniel Stenberg <daniel_at_haxx.se> wrote:
> > So for instance, if you would like to do WPAD/PAC, you'll need to install a
> > plugin that provides a javascript interpreter (currently mozjs; webkit, etc
> > soon to come). So for the basic use case "have basic proxy configuration",
> > libproxy fits the bill. For the case of "I want it to use GNOME/KDE and
> > Mozilla", libproxy fits the bill.
>
> Sure, but when you bring in libproxy as the new golden way of detecting proxy,
> I think just extracting it from GNOME, KDE and Mozilla as long as it isn't
> PAC, is rather half-baked IMHO.
>
> In fact, I've personally never felt a need for GNOME, KDE or Mozilla
> auto-detection but I've felt the need for PAC parsing...

First, we don't extract info from Mozilla (Mozilla should use
libproxy). My above use of Mozilla == PAC parsing.

Second, the issue here is user experience (which right now sucks). On
a typical UNIX system there are hundreds of network enabled programs
and probably more than a dozen "places" to store proxy configuration.

Take for instance the GNOME user. I set my proxy configuration to
Autodetect in the GNOME proxy preferences. Crap! Only epiphany
actually respects that setting because it is the only app with PAC
execution... So I track down my sysadmin to ask for the proxy
hostnames/ports. He doesn't want to give them to me because the PAC
does load balancing, but he reluctantly agrees. So I go back into the
GNOME proxy preferences and set my proxy to "manual." Finally, Pidgin
now respects my proxy settings. But none of my command line apps do.
I switch terminals from aterm to gnome-terminal because it reads the
proxy settings and sets http_proxy in the environment, so now command
line apps work (but apps in my existing gnome-terminals don't pickup
proxy configuration changes). So now I kick off a downloading job and
walk to the food court. NetworkManager picks up the new Wifi AP and
switches networks. Great! Only my download sesion is still looking
for the old proxy. On this network I don't even know the correct
proxy settings. Argh! I open up Konqueror, but it totally ignores any
proxy settings I set in GNOME, so I have to configure it manually.
Same for apt-get, eclipse and svn, as well as any of the other dozens
of apps with their own proxy configuration files. So now, even in my
small use case, every time I change networks I have to MANUALLY
configure my proxy settings in 6 places: GNOME, Konqueror, apt-get,
eclipse and svn. I'd like to point out that this is a REAL world
scenario, one that users at my company deal with every day. The
Windows world is just as bad.

How does libproxy solve this? libproxy solves two specific problems:
1. Where do I read the config? We scan for which config to use:
  - Scan order can be hard-coded by the admin (/etc/proxy.conf) to
lock down configuration or set by the user via an envvar
  - Default order is something like (uses categories):
    * Check user-wide configuration sources (LDAP, file, etc)
    * Check what session we are running in, use that session's config
(GNOME/KDE/etc)
    * Check system-wide configuration sources (LDAP, file, etc)
    * Check envvar
    * If we provide WPAD capabilities, default to "wpad://", otherwise
"direct://"
  - We also automatically pick up changes to config *as they happen*,
so you don't have to restart your app to get these changes, just make
another request like normal
2. How do I interpret the config I just read?
  - If WPAD/PAC and we have WPAD capabilities, resolve this to a
hostname/port by executing the PAC
  - If url starts with https://, try the https proxy first, then http,
then socks
  - If url starts with ftp://, try the ftp proxy first, then http, then socks
  - If url starts with http://, try http first, then socks
  - return the proxy type, hostname and port (ie.
"http://proxy.company.com:8080") or direct (ie. "direct://")

This provides a great user experience. Which config to use and how to
use it is always done in a consistant and predictable way and means
that all applications do what the user *expects* them to do.

I hope this clearly explains the vision of what we are trying to accomplish.

Nathaniel
Received on 2007-12-23