October 2004 - Dillo-dev - lists.mailman3.com

Re: [Dillo-dev]dillo-0.8.3-rc2 ready for download

by Jorge Arellano Cid

On Tue, Oct 19, 2004 at 10:16:34AM +0100, robert w hall wrote: > In article <20041018191501.GM9792(a)dillo.org>, Jorge Arellano Cid > <jcid(a)dillo.org> writes > >Hi there, > > > > The new dillo-0.8.3-rc2 is ready for download and testing! > > > > It's basically the same as rc1, but with the race condition on > >the file dpi solved. It also uses a dpi server instead of a dpi > >filter so please beware and remove: > > > > /usr/local/lib/dillo/dpi/file/file.filter.dpi or > > done - :-) :-) > > [...] > > Feedback is very welcomed. After you say it's OK, it will be > >officially announced as dillo-0.8.3. > > > > Download URL: > > > > http://www.dillo.org/download/dillo-0.8.3-rc2.tar.bz2 > > > > > seems to compile OK on a playstation2 with https enabled > > dpi_parse_token gives an ERROR from open_url each time when trying to > read the filename, > before successfully executing start_send_page... > I presume this is an intended untidyness ? Yes. Before sending the dpi request to the server, a tentative connection is made to be sure it is running. If it's not, a new server is launched. Notwithstanding the untidiness exists ;), essentially it consists in giving a scary message instead of a more meaningful one. > Keep up the good work Thanks. We hope to. -- Cheers Jorge.-

Oct. 19, 2004

Re: [Dillo-dev]Re: comment from ps2 group on 0.8.x

by robert w hall

In article <20041019201134.GC2745(a)dillo.org>, Jorge Arellano Cid <jcid(a)dillo.org> writes >On Tue, Oct 19, 2004 at 07:33:18PM +0100, robert w hall wrote: >> >> >> >> Jorge >> This from playstation2 group - I've asked him to ty the rc2 version >> and/or clarify which 0.8.x version didn't render properly >> Bob Hall > > Thanks. > > I received this email and the former on my personal email >address. AFAIU you're on dillo-dev so I answered there, and to be >sure this one goes to dillo-dev and to your address. > > Please use dillo-dev in the future. OK - but I rather presumed there was no point in filling up the list with 'OK' from 60 different obscure machine-types and besides, I like anonymity :-) -- robert w hall

Oct. 19, 2004

[Dillo-dev]Re: Dillo potential DOS via redirect loop

by Jorge Arellano Cid

Hi Kelson, On Mon, Oct 18, 2004 at 04:39:34PM -0700, Kelson Vibber wrote: > I was attempting to pull up the bug database for Wordpress > <http://mosquito.wordpress.org/> in Dillo 0.8.3rc2, and noticed that the > browser froze when I clicked on the "View bugs" link. After I killed it > and re-launched it from a command line, I saw it spewing Nav_open_url > messages over and over, alternating between these two lines: > > Nav_open_url: Url=>http://mosquito.wordpress.org/view_all_bug_page.php< > Nav_open_url: Url=>http://mosquito.wordpress.org/view_all_set.php?type=0< Yes, it happens... > > I'm not entirely sure what the site is trying to do, but Firefox, Opera > and IE all seem to make it through okay. I suspect it's something like > this: > > 1. view_all_bug_page.php checks for a cookie. It doesn't find it, so it > redirects (302) to view_all_set.php?type=0 > 2. view_all_set.php sets the cookie, then sends the browser back to the > original page. > 3. Either Dillo hasn't accepted the cookie and view_all_bug_page.php > sends the redirect again, or Dillo has already cached the 302 response > and jumps to view_all_set.php anyway. > > Adding mosquito.wordpress.org to cookiesrc doesn't make a difference. Currently Dillo's cache is handling HTTP 30x answers as cacheable redirections. This is more a lack of implementation than a BUG (there's no code to handle 302 answers now). > > Based on the libwww-perl HEAD utility (which breaks out of the loop > after 7 redirects) and just telnetting to port 80, I've found the following: > > - They're using a 302 (temporary) redirect on both scripts > - They're setting a cookie on view_all_set.php. > - They're using relative URLs in the Location header (which I think is > technically not allowed, but has been used in practice for years.) Dillo handles relative locations. > Regardless of whether this setup is valid, it *does* make Dillo stop > responding. There is at least one bug here -- Dillo isn't detecting the > redirect loop and breaking out of it -- and possibly two (if it's > caching the 302/temporary status). Yes, there're two problems. Dillo hogging the CPU is a BUG that'd be better fixed for 0.8.3. The caching problem is a large issue that needs much more time to tackle. The cache problem is very interesting: if a browser happens to follow the SPEC, it becomes easy to abuse (e.g. pragma: no-cache advertising). OTOH, some sites can require to refresh some page contents in order to keep some meaningful state (HTTPS services usually use cache directives). Maybe as it happens with cookies, just allowing certain cites and honoring HTTP cache directives from that set only, is a good solution in the long term. I'll try to find a way to catch the redirection loop hog... -- Cheers Jorge.-

Oct. 19, 2004

Re: [Dillo-dev]Re: anchor names

by Sebastian Geerken

On Tue, Oct 19, Matthias Franz wrote: > Dear Sebastian, > > thanks for the quick bugfix. > > On Sun, Oct 17, 2004 at 04:32:09PM +0200, Sebastian Geerken wrote: > > The changes also make the viewport check, whether anchor names are > > unique. If not, g_return_if_fail is called, which messages should not > > be printed normally (and "normally" includes faulty web pages), > > instead, normal HTML error messages should be shown. Probably, the > > best solution is to add a function a_Dw_gtk_viewport_check_anchor(), > > which returns, whether an anchor is already defined. If it returns > > TRUE, an appropriate message is shown, and the anchor is not added. > > Why don't you let a_Dw_gtk_viewport_add_anchor return a result: > FALSE = ok, TRUE = anchor already defined and not changed > Then a_Dw_page_add_anchor could pass this on to html.c, where > my patch would produce the HTML warning. > Otherwise one would look up the hash table twice, once in > a_Dw_gtk_viewport_check_anchor and once in a_Dw_gtk_viewport_add_anchor. See latest commitment, something like this has been added. There are also now HTML warnings, if equal anchors have been added twice. For those, who are interested, I've attached the changes as patch. Sebastian

Oct. 19, 2004

Re: [Dillo-dev]Re: dillo patch: anchor names

by Matthias Franz

Hi Richard, thanks for your comments! On Fri, Oct 15, 2004 at 04:35:29PM -0400, Richard Page-Wood wrote: > I do know a bit about HTML and XHTML, though, and I was wondering > about your doctype-sniffing patch. As I understand it, you're trying > to distinguish between HTML 4.01 and XHTML 1.x by sniffing the doctype > and giving appropriate warnings for invalid markup. Are you also going > to alter the rendering for XHTML? Certainly not as part of my patch. It's origin was simply the observation that Dillo refused anchor names like "Dürst" which are allowed in HTML if defined with the "name" attribute (see Section 12.2.3 of the HTML 4.01 spec). > There's a good article here: > > http://www.hixie.ch/advocacy/xhtml > > which talks amongst other things about the impossibility of correctly > identifying an XHTML document which might be of interest to you. Having looked at this article and the references given therein, I don't feel anymore that it would be a good idea to try and figure out whether the document type is HTML or XHTML. I still like the idea of supporting XHTML in some way, mostly because XML lacks many of the strange features of SGML that make parsing difficult. For example, "<" and "&" are not allowed as ordinary characters in XML. But this has nothing to do with anchor names, so I will remove the XHTML parts of the patch (unless someone complains). Jorge: Are you still interested in evaluating <!DOCTYPE> to figure out the HTML version? Maybe it would be ok for a small browser like Dillo to stick to HTML 4.01. All the best, -- Matthias Franz Section de Mathématiques, Université de Genève, Suisse

Oct. 19, 2004

[Dillo-dev]Re: anchor names

by Matthias Franz

Dear Sebastian, thanks for the quick bugfix. On Sun, Oct 17, 2004 at 04:32:09PM +0200, Sebastian Geerken wrote: > The changes also make the viewport check, whether anchor names are > unique. If not, g_return_if_fail is called, which messages should not > be printed normally (and "normally" includes faulty web pages), > instead, normal HTML error messages should be shown. Probably, the > best solution is to add a function a_Dw_gtk_viewport_check_anchor(), > which returns, whether an anchor is already defined. If it returns > TRUE, an appropriate message is shown, and the anchor is not added. Why don't you let a_Dw_gtk_viewport_add_anchor return a result: FALSE = ok, TRUE = anchor already defined and not changed Then a_Dw_page_add_anchor could pass this on to html.c, where my patch would produce the HTML warning. Otherwise one would look up the hash table twice, once in a_Dw_gtk_viewport_check_anchor and once in a_Dw_gtk_viewport_add_anchor. All the best, -- Matthias Franz Section de Mathématiques, Université de Genève, Suisse

Oct. 19, 2004

[Dillo-dev]Possible RPM delays

by Kelson Vibber

My main computer at home has been having problems lately. I *hope* it's just the video card (I would expect worse problems if it were the motherboard, CPU, or memory), but I think it's fair to warn you that if 0.8.3 final comes out before I've resolved the issues, I might not be able to build all the RPMs immediately. Kelson Vibber www.hyperborea.org

Oct. 19, 2004

[Dillo-dev]dillo-0.8.3-rc2 ready for download

by Jorge Arellano Cid

Hi there, The new dillo-0.8.3-rc2 is ready for download and testing! It's basically the same as rc1, but with the race condition on the file dpi solved. It also uses a dpi server instead of a dpi filter so please beware and remove: /usr/local/lib/dillo/dpi/file/file.filter.dpi or /usr/lib/dillo/dpi/file/file.filter.dpi Actually it can work with both, but as we want to test the dpi server in the tarball (default) please be careful and be sure to remove the file filter dpi to be testing the file server dpi. (the other change is a minor improvement on the visited link color choosing algorithm). Feedback is very welcomed. After you say it's OK, it will be officially announced as dillo-0.8.3. Download URL: http://www.dillo.org/download/dillo-0.8.3-rc2.tar.bz2 -- Cheers Jorge.-

Oct. 18, 2004

Re: [Dillo-dev]Re: race condition patch]

by Jorge Arellano Cid

-- Cheers Jorge.-

Oct. 18, 2004

[Dillo-dev]Re: anchor names

by Jorge Arellano Cid

Hi there, This is half an email forward and half an answer. On Sun, Oct 17, 2004 at 04:32:09PM +0200, Sebastian Geerken wrote: > Hi, > > the dillo-dev mailing list does not seem to work, I always get an 550 > error, so I forward you the mail, which I did not succeed to send to > the list. > > Sebastian Now, 18 Oct, it works for me. I'm answering to dillo-dev because my test mail succeeded. > Date: Sun, 17 Oct 2004 15:54:40 +0200 > From: Sebastian Geerken <sgeerken(a)dillo.org> > Subject: Re: [Dillo-dev]anchors_table not cleared > To: dillo-dev(a)auriga.wearlab.de > Mail-Followup-To: Sebastian Geerken <sgeerken(a)dillo.org>, > dillo-dev(a)auriga.wearlab.de > > On Fri, Oct 15, Matthias Franz wrote: > > I'm writing a patch for a better treatment of anchor names in HTML pages. > > During this, I've come across the following bug in Dillo. > > > > Jorge: I think this is what produced the bug in the patch I sent you. > > > > Entries are never removed from the hash table anchors_table, which stores > > the anchors of a page (see dw_gtk_viewport.c). This means that whenever a > > new page is displayed in the same viewport, the old anchors remain in > > the hash table, but their keys are overwritten. Like in this example: > > (The "###" lines are debug information I've inserted.) > > > > [...] > > > > Obviously, the anchors_table must be cleared whenever a new page is > > displayed. I don't know the dw* part of Dillo very well, and the > > connection between the html structure and the viewport seems to be quite > > indirect. Can anyone suggest a fix? > > The latest commitment in CVS fixes this, the patch is also > attached. Jorge, I'm not sure, whether this should be included into > the release, since the changes are rather big, and currently, it only > fixes a memory leak. I'd prefer to leave it out of rc2. It's been more than four months since our last release. The one following 0.8.3 is going to have the new abstraction layer for Dw, and other changes, so just in case it takes some time to stabilize it, it'd be very good to have a solid 0.8.3 out there. I'll prepare the dillo-0.8.3-rc2 tarball ASAP and write back when it's ready for download... > > The changes also make the viewport check, whether anchor names are > unique. If not, g_return_if_fail is called, which messages should not > be printed normally (and "normally" includes faulty web pages), > instead, normal HTML error messages should be shown. Probably, the > best solution is to add a function a_Dw_gtk_viewport_check_anchor(), > which returns, whether an anchor is already defined. If it returns > TRUE, an appropriate message is shown, and the anchor is not added. Agreed. -- Cheers Jorge.-

Oct. 18, 2004