[Top][All Lists]

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

[Bug-wget] [patch] new variant of Dominique Leuenberger's libproxy patch

From: Lucian Muresan
Subject: [Bug-wget] [patch] new variant of Dominique Leuenberger's libproxy patch (was: wget reports: libproxy suggest to use 'direct://')
Date: Wed, 18 Apr 2012 19:19:00 +0200
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1


I was in real big need of this feature in wget, I'll explain below why...

On 20.03.2012 18:30, Ángel González wrote:
>> Is it a bug? My original message was about asking what the meaning was
>> of this output...
> I have looked at the patch and it apparently works fine. In fact, there's a
> comparison to not do anything else if libproxy returned direct://
> The only bug seem to be that such message is confusing. It should probably
> have been shown only with --debug.

I think the reason why one would want to use libproxy support would
rather be the possibility to get proxy information from a PAC file.
Imagine the situation inside a corporate environment where such a PAC
file might be several pages long, so setting just one proxy server would
only work for few URLS.
For that, libproxy itself has to be built with support of a pacrunner,
which might be a dependency to webkit-gtk, xulrunner or other mozilla
derivates which all can parse JavaScript. Of course, this is out of
scope here, as far as wget is concerned, it should be just either build
with or without libproxy support. If one wants to explicitely ask
libproxy to use a specific PAC file in order to get the right proxy
settings for the specific URL, the environment variable for the
respective proxy type (http_proxy, https_proxy or ftp_proxy) has to be
set like
"http_proxy=wpad://" or
and then libproxy will do the rest (see comments 14 to 19 of
http://code.google.com/p/libproxy/issues/detail?id=129 for details). But
in the old variant of the patch it failed on this, because the scheme
"pac+http" is rejected by wget before libproxy gets the chance to see
it. My patch runs libproxy before falling back to the original code (it
should mostly even not need to fall back if libproxy did the job right)
and just pass the proxy setting to wget.
There was one more problem with the old patch, the debug statements used
code which was only built when debug was generally enabled, so I moved
the #ifdef DEBUG_ENABLED statements inside the definition of
debug_logprintf, that way the code is either an empty function, or one
which only logs when we built with debug upport and also request debug
output. At least it can no longer fail on linking...
Would be nice if this feature could be included in the next release,
what do you think? Of course, main credits go to Dominique, I only
re-arranged his patch.


Attachment: wget-libproxy_20120418.patch
Description: Text document

reply via email to

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