[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-wget] Inclusion of libproxy as a dependency for wget

From: Dominique Leuenberger
Subject: [Bug-wget] Inclusion of libproxy as a dependency for wget
Date: Wed, 19 Aug 2009 12:05:56 +0200

Hi everybody,

After a short notice last night on the IRC channel, I was advised to bring the 
topic to the mailing list for broader audience and less 'time zone'

I think it could be of interest to gain libproxy support in wget.
The scope of libproxy is NOT connecting to the proxy and doing all the work. 
It's scope is to find the proper configuration on the system and letting
your application know which prox{y,ies} to use.

Current situation in wget:
wget reads the proxy settings from {http[s]|ftp}_proxy in order to find if a 
proxy is needed and then will try to match the ignore if it's still
needed. For normal situations / configurations this is nice and works.

My vision:
Me as a user do not care of environment variables at all. I'm a gnome user 
(could be KDE too, does not matter here!) and set the proxy in my DE's
control center, network proxy. At this point, just after changing it, the 
envvar is not updated and wget uses outdated information. Even worse, if I
define a 'proxy autoconfiguration url', wget just can't make use of it. Same 
applies if I select 'Autodetect proxy settings'. In this case, wget just
does not know about proxies.

The solution:
*libproxy* (Do I need to say more?)
Ok, I'll try to elaborate a bit more: libproxy is the missing part for you in 
the chain. all wget at the moment knows is envvar. libproxy knows this
too, as the last resort in case nothing else can be found (not really last... 
there are further fall backs). But it offers in plus:
- Finding the appropriate settings based on your desktop environment. This 
means, if you're running a gnome session, then the gnome settings are
relevant, in a kde session the kde settings. It is irrelevant if the app is a 
kde or a gnome app.
- In case the settings point to a proxy auto configuration script, libproxy 
will download the script, cache it (for performance reasons) pass the
script through a url parser and tell you which proxy / proxies to use. 

For wget I had a short look at the code yesterday and it looks like all the 
changes needed would go into retr.c, especially the function getproxy.
Already correctly done is that this function is called for every single URL 
that is tried to be retrieved (this is important).

I'll be working a bit next days on integrating libproxy support into wget, 
including needed modification on configure to have it optional (not all
distros have it yet, even though it is fast spreading, as gnome adopted it 

If you have any comments, questions, hints, objections, considerations, blames, 
<extend the list>, please let me know. I'm sure we'll be able to
resort most of the things together in a way perfect for every situation.

Best regards,
Dominique Leuenberger

reply via email to

[Prev in Thread] Current Thread [Next in Thread]