- Dillo-dev - lists.mailman3.com

Re: dillo 0.73 not compiling on slackware 3.9 ( libc5 )

by Jorge Arellano Cid

Hi Matti, On Tue, 13 Jan 2004, matti christensen wrote: > > do You remember short email discussion with me; compiling Dillo 0.73 on > slak 3.9 with resulting binary which did not run ( i sent an email after > this one and adding threads library etc...) Yes I do. > do You think it might be possible to make Dillo run on this laptop ?! Absolutely! I was about to suggest you trying older versions of dillo to find out which one is the last one to compile/run cleanly on slk3.9, but I had a feel that I've seen this before: > Gdk-ERROR **: Fatal IO error 0 (Success) on X server :0.0. And then I remembered that the standard X server packages that come with slk are not reentrant (thread safe), and that some time ago I had to uprade it and some libs of X from a site of a nice german guy that has done it. I don't have the link now, but for instance look at: http://www.linuxsavvy.com/resources/ There you'll find Reentrant XFree86 3.3.3 Libraries. You can try those, or google until finding 3.3.6 reentrant or recompile them reentrant. I Hope this helps Cheers Jorge.- PS: Please let me know hot it goes.

Jan. 15, 2004

font segfault

by Johann Koenig

Sometimes dillo just segfaults on me, and I'm finally able to reproduce it. The log from the console is: jkoenig@note:~$ dillo dillo_dns_init: Here we go! Enabling cookies as from cookiesrc... Nav_open_url: Url=>about:splash< Nav_open_url: Url=>http://kernel.org< Dns_server [0]: kernel.org is 0x80ef838 Connecting to 204.152.189.116 HTML warning: line 43, unexpected closing tag: </CENTER>. -- expected </a> HTML warning: line 157, <td> or <th> outside <tr> HTML warning: line 406, unexpected closing tag: </BODY>. -- expected </a> Nav_open_url: Url=>http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1/2 .6.1-mm2/announce.txt< Connecting to 204.152.189.116 ** CRITICAL **: file dw_style.c: line 385 (Dw_style_font_new_internal): assertion `font_attrs->name != NULL' failed. ** ERROR **: Could not find any font. aborting... Aborted I went to kernel.org and tried to view the changelog for 2.6.1-mm2 -- -johann koenig Now Playing: Metallica - ...And Justice for All : ...And Justice For All Today is Boomtime, the 12nd day of Chaos in the YOLD 3170 My public pgp key: http://mental-graffiti.com/pgp/johannkoenig.pgp

Jan. 12, 2004

Re: spam-safe and basic auth

by Jorge Arellano Cid

On Wed, 7 Jan 2004, Francis Daly wrote: > On Fri, Dec 19, 2003 at 05:45:50PM +0000, Francis Daly wrote: > > On Fri, Dec 12, 2003 at 06:32:54PM -0300, Jorge Arellano Cid wrote: > > > [...] > > > On to another topic, have you had a look at the basic > > > authentication patch by Madis and Tor? > > I've spent a few evenings on this now, and have through the mzz auth > patch, and tried implementing something similar myself. I don't see how > mzz avoids the "redirect loop" problem which it seems to generate. I got > the full mzz-wtab.diff file which applies cleanly to the 0.7.3 code, and > it compiled and ran okay, but failed to even ask for authentication when > I tried it against a 401 page. And it gave the "redirect loop" warning. > > So "doesn't work for me" is the best I can report about it for now, > unfortunately. I'm moving this thread to dillo-dev, just in case Madis or somebody else is interested in helping the development of this feature. > I believe that a 401-handler could be broadly analogous to the 30x > handler, Cache_redirect(). Within Cache_parse_header(), I set a new > value CA_Unauthorized for entry->Flags for a 401 response; and then > within Cache_process_queue(), if that value is set, call the new > Cache_reload_auth() just after where Cache_redirect() is called. Interesting idea. > For adding the Authorization: header, I just edit Http_query to > include an appropriate header if URL_RealmAccess is set (it's not used > elsewhere, and looks like it was intended for 401 usage); and within > Cache_reload_auth(), I set URL_RealmAccess and URL_E2EReload and call > a_Nav_push(). It seems to work fine for authentication pages with no > images, and for authentication pages with images which don't require > authentication. But images that *do* require authentication cause > breakage. Yes, a_Nav_push is for root urls (WEB_RootUrl). > The difficulty is in how to handle non-WEB_RootUrl requests -- I > was following Cache_redirect() for inspiration, and it appears that > Cache_redirect() just ignores them, and I don't see a clean way to > manage them. > > Why are sub entity redirections ignored? Is it because of > security/privacy concerns, or because it was difficult to do them > right? Because the only sub-entity type that dillo handles is image, and near 99% of image redirections is advertising, so given the state of the web, it's a feature! What could be done: my first thought is to check whether an URL (root or not) requires authentication (a flag). If it requires it and we have the auth cached, load it, if not, ignore. > If the former, then whatever the original plan was (using > a_Cache_open_url() or similar) would be worth learning. If the latter, > then unfortunately, in order to handle authentication it's going to have > to be addressed some time :-( Unfortunately I have little time to devote to this design, as I'm given priority to pushing the next release, that is, stabilizing the dpi framework (hopefully done), making the HTML warnings go into a window (not stdout), and adding an HTML error counter together with a "combat mode" parsing feature (a way to try to render pages full of errors in a simplistic but viewable way). Ah, and also giving a check to Keyb-nav-4 if it comes my way... > As I see it, the ideal situation would be that when Cache_parse_header() > finds the 401, it would be useful to check whether we have suitable > authentication credentials, and if so, initiate a new http request which > will feed into (and replace) the same "entry". Doing that directly, > though, probably cuts across too many layers of abstraction. Funny, quite the same I described above! No not that many layers. As you noticed, it can be viewed as a redirection (that asks for credentials on root pages.). It should be possible to implement it this way without breaking the current model. > (I did all my testing on the 0.7.3 codebase; I've just had a look at > CVS and it doesn't appear significantly different.) > > I'm quite happy to keep working on getting authentication working > (Basic, initially, but with the possibility of adding Digest or > anything else in the future) -- if you have any known-dead-ends from > implementing Cache_redirect, or ideas of "safe" ways to intercept the > cache handling, I'd appreciate hearing them. Try to prototype the idea above. It should work. Sorry for not being of more help by now. Cheers Jorge.-

Jan. 7, 2004

Re: [Dillo-dev] Re: dillo configuration on AIX

by Andreas Schweitzer

Hi, > > I have a question whichmight be a short configuration question. I'm > > trying to build dillo 0.7.3 on AIX 4.2.1 using gcc. I already installed > > and tested gtk and pth. FWIW, I used to run dillo 0.6.6 on AIX 4.3.2 quite extensively. > Pth is different from pthread (POSIX threads). I did not install pth either. > > when configuring dillo it says it can't find pthreads. In fact it tries > > -pthread. I'm sure that AIX has native threads, > http://home.t-online.de/home/Andreas.Steinmetz/unix/pthreads.html The odd thing is contrary to the above explanation, it worked for me with gcc and -pthread (and not -pthreads). I'm not quite sure which version of gcc I used back then. But gcc can (and should be) configured to do the right thing when called with -pthread. Using xlc instead of gcc however, was quite a bit of a mess ... I got it compiled somehow :-) ... but would need to look up the details. I beleive the explanations given in the web page refer to xlc. Now, all that does not really help the original poster :-) ... what would help is some more detailed output, maybe some portions of config.log and to some degree the output of gcc -v lslpp -l | egrep -i 'thread|xlc|gcc' and that possibly on-list ;-) Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Jan. 7, 2004

Re: dillo configuration on AIX

by Jorge Arellano Cid

On Wed, 7 Jan 2004, Riccardo wrote: > Hello, Hi! > I have a question whichmight be a short configuration question. I'm > trying to build dillo 0.7.3 on AIX 4.2.1 using gcc. I already installed > and tested gtk and pth. Pth is different from pthread (POSIX threads). > > when configuring dillo it says it can't find pthreads. In fact it tries > -pthread. I'm sure that AIX has native threads, Yes, but our configure doesn't detect them yet. Although this should not be hard to do: Get the detected target system type string from the configure script. That is, near the third line of output, it says something like: checking target system type... i586-pc-linux-gnu Then add that option to "configure.in" inside the case statement for pthreads. Something like: [...] case $target in *-*-linux*|*-*-solaris*) AC_CHECK_LIB(pthread, pthread_create) ;; + *-*-aix*) + AC_CHECK_LIB(pthreads, pthread_create) + ;; [...] Then follow the directives at: http://home.t-online.de/home/Andreas.Steinmetz/unix/pthreads.html That is basically adding a call to pthread_init() somewhere in main() in dillo.c. Run autoreconf or autogen.sh, configure, make, tweak and send some feedback! :-) > but in any case -lpth > should be used to use libpth. I'm not an expert with AIX development, > I'm using version 4.2.1. > Can dillo be linked against lpth? other projects usually have a > configure option top select the threading model. Against Pth, no. Cheers Jorge.-

Jan. 7, 2004

MINISTRY OF MINES AND NATURAL RESOURCES,SIERRA-LEONE

by BRIGEDIER EVANS GIWA

Dear sir, I PRESUME THIS LETTER WILL NOT BE A SURPRISE TO YOU. I am Brigedier Evans Giwa, a soldier by profession, formerly a director with the ministry of Mines and Natural Resources in SIERRA-LEONE before the out - break of the civil war in Sierra-Leone. When I was the director with that ministry, I acted as a link between foreign buyers of Diamonds and the Sierra-Leonian government, but ae a result of the civil war, I diverted the sum of US$36.5 million meant for Sierra-Leone government to a security company in Europe. All I need from you.: (1)Coming up with a viable business that we can invest this fund in. (2)To act as the beneficiary of the said money, as I cannot act in this capacity as I`m still directly or indirect involved in the peace negotiations going on in my country now. (3)To clear the money with the security company in Europe and lodge the money into an account we shall both run. After acknowledging this letter,and indicating your interest and willingness in my proposals, we shall arrange for a meeting in Europe to discuss your areas of interest and investment. As a christain, I will like to invest 20%of the money to help the less priviledged in the society.You willget 25% of the total money for your assistance and 5% will be set aside to offset whatever expenses incurred during the duratation of this transaction. Do kindly contact me through the below email address for further discussion and forsecurity reasons,this business remains confidential. Your Sincerly Brigedier. Evans Giwa giwa(a)consultant.com or egiwa(a)lycos.com

Jan. 7, 2004

Improved stability patch for dpi framework!

by Jorge Arellano Cid

Hi Ferdi, (et all) After spending the last weeks hunting for some bugs in the dpi framework deeply, I've succeeded to track them down, and finally, to fix them! From time to time there were multiple dpid instances, this was due to a race condition while waiting for dpid to be "online"; if the process took around a second, dillo could end launching multiple instances of the daemon (I left a commented sleep in the dpid code that served to reliably reproduce it). Another nasty bug was that sometimes dillo crash-locked when requesting a dpi service, for instance: launch dillo -> ask for bm -> kill dpid -> ask for bm -> crash ...this was because of FD inheritance! The bm dpi survived, and kept its parent's FD open, so the connect-test succeeded but there was no server to answer. This couple was really hard to track. As a by-product, lsof showed a FD leak in dpi.c (one per dpi request) and another for dillorc. All of these bugs are fixed in CVS. The good news is that this is a big step towards 0.8.0 release because the stabilization of the dpi-framework is a necessity. There is still at least one pending thing to polish, but it is not a big problem to live with it in 0.8.0 because it causes little harm. This is: if dpid crashes (or is killed), the dpi servers will survive, but the new dpid will launch new processes for them (the old ones will last until their bore-time is reached). No crash, no locks. My first idea was to make a connection-test to dpi servers from dpid at start time, but unfortunately, the parent-child relationship would be lost for the second dpid, so we have to find another way to tell dpid that a dpi-server has finished. The "srs" may be used, although it may be a bit tricky to do when the dpi server has crashed; anyway, the connection test from dpid can detect the crash and bypass the old server with a new one. Cheers Jorge.-

Jan. 5, 2004

Re: dillo 0.73 not compiling on slackware 3.9 ( libc5 )

by Jorge Arellano Cid

On Sat, 3 Jan 2004, matti christensen wrote: > Hello ! Hi! > > In Your README You asked to email comments on compiling Dillo on libc5, > and here's some of mine. Good, the first in a long time. > - slackware 3.9 is the last one with libc5 ( glibc 2.0.7pre6 ) and ( gcc > 2.7.23 ) No problem, I use slackware, and have deployed dillo on it in much earlier versions. > - kernel is the latest of 2.0 -series ( 2.0.39 ) which i have compiled > according to attached config and dmesg > > - i also compiled following in for Dillo ;o) > > --- XFree 3.3.6 > --- glib 1.2.9 > --- gtk+ 1.2.9 > --- jpeg-6b > --- libpng 1.2.5 > --- libtiff 3.5.7 > --- zlib 1.1.4 > > - when i try to make Dillo after making the changes to dns.c as You kindly > adviced, compiling stops to src/IO/mime.c saying "mime.c:34: parse error > before `static'" OK. It seems to be the G_GNUC_UNUSED directive. Remove lines 31 to 40 in mime.c. It should stop complaining about mime.c. If this is true, as I do expect, do the same with html.c and IO/Url.c. Please report me how it goes to fix it in current CVS. Cheers Jorge.-

Jan. 4, 2004

ASK FOR HELP:"view source" and edit data to send.

by FUN TOES

Some websites can't be visited by dillo.So I think of writing a patch to view the raw data(including header) from the server and send the raw data modified manually to the server. It is very easy to edit the data to send by modifying the function Http_send_query().But I do not know how to get the raw http data from the server.What is the function that I need read deeply? And I do not think IO_read()is a good selection.The function send raw data to html parse maybe a good selection.But I am a newbie,and I have difficuty in finding the correct function. Would you like help me find it?Appreciation for your help. -- ___________________________________________________ Check out the latest SMS services @ http://www.operamail.com, which allows you to send SMS through your mailbox. Powered by Outblaze

Jan. 2, 2004

Best wishes for year 2004

by Jorge Arellano Cid

Hi There, It's early in the morning here in Chile, and I know that in Europe the clock is around 4 to 6 hours ahead, hopefully still in time to send my greetings and best wishes to all the people scattered around the world that participate of dillo-dev. Somewhere inside this december the Dillo project completed four years of existence and continued development. Please excuse me for not displaying a birthday cake picture at the home page; I didn't have the time, but the will to share and celebrate the event still remains! I spent the last months of this year making the arrangements to be able to keep working on dillo the 2004, and hopefully more... It seems that these efforts will flourish and let me work through this new year with renewed energies and hope: let 2004 be a great year for the Dillo project! Cheers & Best wishes to all! Jorge.-

Dec. 31, 2003