- Dillo-dev - lists.mailman3.com

web bug save?

by corvid＠lavabit.com

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.

Jan. 12, 2010

Cookies performance

by Johannes.Hofmann＠gmx.de

Hi, I noticed that since the recent DPI update pages which use cookies load slower (e.g. fltk.org) Do others also see that? It could also be OS specific. Cheers, Johannes

Jan. 12, 2010

web bug save?

by Johannes.Hofmann＠gmx.de

On Tue, Jan 12, 2010 at 06:50:01AM +0000, corvid 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 the idea is to always use command line arguments instead of environment variables? Sounds good to me. Cheers, Johannes

Jan. 12, 2010

web bug save?

by corvid＠lavabit.com

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.

Jan. 12, 2010

web bug save?

by corvid＠lavabit.com

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.

Jan. 12, 2010

HTML4 testpage containing all elements

by onepoint＠starurchin.org

On Mon, Jan 11, 2010 at 01:46:19PM +0100, Johannes Hofmann wrote: > does anyone have a test page containing all possible HTML4 element? There's a test suite at http://www.w3.org/MarkUp/Test/HTML401/current/tests/ but it's split into multiple pages. I couldn't find an all-in-one version. Regards, Jeremy Henty

Jan. 11, 2010

HTML4 testpage containing all elements

by Johannes.Hofmann＠gmx.de

Hi, does anyone have a test page containing all possible HTML4 element? Cheers, Johannes

Jan. 11, 2010

want to test some experimental cookies code?

by Johannes.Hofmann＠gmx.de

On Sun, Jan 10, 2010 at 01:11:37AM +0000, corvid wrote: > Jorge wrote: > > AFAIS, you're our cookies expert now. > > Please feel free to replace the current dpi when you see net gain. > > Committed. Excellent!

Jan. 10, 2010

dpi send cmd error msg (Re: [Dillo-dev] Re: even more cookies SECURITY)

by corvid＠lavabit.com

Jorge wrote: > On Mon, Jan 04, 2010 at 11:38:03PM +0000, corvid wrote: > > Do we currently have anything that needs to be > > fixed/implemented before a release would be sensible? > > Not that I remember. The only problem I recall was the error > message you reported with cookies and later seemed to be working > somehow. a_Dpi_send_blocking_cmd() gets upset when Dpi_blocking_read() doesn't get anything. So in the cookie dpi's srv_parse_tok(), after the Cookies_set(), I tried putting a a_Dpip_dsh_write_str(sh, 1, "text"), and that makes the error msgs go away for me.

Jan. 10, 2010

want to test some experimental cookies code?

by corvid＠lavabit.com

Jorge wrote: > AFAIS, you're our cookies expert now. > Please feel free to replace the current dpi when you see net gain. Committed. Is there an easy way that we could get dpid to send the cookies dpi a DpiBye to end the session on demand? I tried this once, long ago, and the problem was something like dpid expected a reply, so it kept restarting the dpi to send it the bye.

Jan. 10, 2010