I wrote:
I wrote:
I wrote:
Johannes wrote:
On Thu, Dec 31, 2009 at 12:27:36AM -0300, Jorge Arellano Cid wrote:
Sometimes I wonder whether connecting through to a TOR network could help us a lot with it.
You can already use dillo with privoxy and tor. We could perhaps make it more convenient to configure such a setup. We also would need to make sure that really all requests go through the proxy, e.g. I'm not sure, whether wget called from dowload.dpi uses the proxy from dillorc.
I have warnings in the FAQ and dillorc that the wget env variables would need to be set appropriately, but it would be nice to have dillo send that to the dpi in requests so that it can set the environment for sure before execing wget.
I just committed a patch to set the environment variable from the preference if it wasn't already set.
issues: - maybe we should have an ftp_proxy pref, too. - ISTR that dillo doesn't understand user/pass in URLs. This means that dillo doesn't do the right thing if - the env var has the user/pass - dillo is setting the env for wget.
It turns out that if I want to add the ability for ftp/downloads to do the right thing with the no_proxy pref as well, I would have to send a no_proxy arg to the dpi.
It would be cleaner to send the proxy URL to the dpi (and set/clear it there in the environment for wget) every time that it's needed than to have the proxy URL in the environment and send a no_proxy arg when it's needed.
So I'm going to back out that change.
This turns out to be a somewhat complicated situation. I naively imagined that whatever I found in wget's 1500-line manpage was what there was, but since wget is a gnu program, it's a subset selected who-knows-how. wget understands the http_proxy, https_proxy, and ftp_proxy environment vars. dillo understands the http_proxy environment var. If it is not set, dillo will use the http_proxy pref. dillo uses its http_proxy value for both http and the https plugin. Whatever we might do to get *_proxy set a certain way in the environment in the downloads/ftp dpis, wgetrc can override them. - should the https plugin use the https_proxy environment var if it's set? I'm leaning toward no. - should dillo try to set the https_proxy env var from the http_proxy pref for the benefit of the downloads dpi? Well, the downloads dpi doesn't like https anyway right now because we haven't given it any sort of #ifdef ENABLE_SSL add argument "--no-check-certificate" #endif, but we could and probably should add the argument. As for the question, ... not sure. (Maybe we should just let wget do all of our https, at least instead of the current plugin.) - should dillo have https_proxy prefs and ftp_proxy prefs? On one hand it might minimize confusion, but then I could take the same amount of space in dillorc to write a big comment explaining all of this. (The unpleasant part of putting things in dillorc or explaining things in dillorc is that I know that no one who upgrades is going to look through it meticulously to see what tiny things have changed.) wget also understands the no_proxy environment variable and wgetrc option. Dillo understands the no_proxy preference. Coincidentally(?), they have the same format. - Should dillo set the env var for wget from the pref if not set? I think so, for the benefit of http downloads. - Should dillo use the env var for itself if set? I kind of don't want to add the complexity. I don't know. (And to get user/pass into wget for proxy, it seems that the proper thing is to stuff them into the env var *_proxy urls.) Anyway, I'm finding this all somewhat tricky to think about.