- Dillo-dev - lists.mailman3.com

patch: Re: [Dillo-dev] patch: meta charset changes decoder

by Johannes.Hofmann＠gmx.de

On Sun, Mar 16, 2008 at 09:34:13AM -0400, Jorge Arellano Cid wrote: > On Thu, Mar 13, 2008 at 04:21:42PM +0000, place wrote: > > Jorge wrote: > > > On Fri, Mar 07, 2008 at 06:17:17AM +0000, place wrote: > > > > This is no sort of proper fix whatsoever, but I was tired > > > > of seeing the "would set charset" message. It's actually > > > > surprisingly useful for remote files, since they're generally > > > > still at the javascript-and-css point at the end of the first packet. > > > > > > In CVS there is a new approach that restarts parsing the whole page. > > > It works with local/remote files, and page title. Please test it. > > > > In the past, I've encountered pages that go > > <head> > > <meta http-equiv="content-type" content="text/html; charset=utf-8"> > > <meta http-equiv="content-type" content="text/html; charset=iso-8859-1"> > > </head> > > > > Here's code just sticking in a flag when meta charset's been seen. > > Committed a slightly modified version. Please check. ebay.com works again for me. Thanks, Johannes

March 16, 2008

libiconv fix for OpenBSD

by jcid＠dillo.org

Hi, On Sat, Mar 15, 2008 at 12:06:17AM +0100, Christian Kellermann wrote: > * Jorge Arellano Cid <jcid(a)dillo.org> [080314 21:40]: > > > > Committed, but in two places! > > Yeah I have seen it. Why is the same code duplicated? Once should > be enough. My original patch contained such one instance of the > tests... When applying the patch, it failed (I don't know why). After a few tries I decided to patch by hand. Redundance removed, and committed. -- Cheers Jorge.-

March 16, 2008

[patch] don't allocate tagnames on stack

by jcid＠dillo.org

On Thu, Mar 13, 2008 at 09:01:37PM +0100, Johannes Hofmann wrote: > Hi, > > here is another patch that avoids some malloc/free calls. > I decided to completely remove tag_name, and to use Tags[tag_idx]. Please check the patch in CVS. BTW, with regard to these optimizations (which I was very fond of), profiling showed me that the zen of speed is to attack the main bottleneck... -- Cheers Jorge.-

March 16, 2008

patch: Re: [Dillo-dev] patch: meta charset changes decoder

by jcid＠dillo.org

On Thu, Mar 13, 2008 at 04:21:42PM +0000, place wrote: > Jorge wrote: > > On Fri, Mar 07, 2008 at 06:17:17AM +0000, place wrote: > > > This is no sort of proper fix whatsoever, but I was tired > > > of seeing the "would set charset" message. It's actually > > > surprisingly useful for remote files, since they're generally > > > still at the javascript-and-css point at the end of the first packet. > > > > In CVS there is a new approach that restarts parsing the whole page. > > It works with local/remote files, and page title. Please test it. > > In the past, I've encountered pages that go > <head> > <meta http-equiv="content-type" content="text/html; charset=utf-8"> > <meta http-equiv="content-type" content="text/html; charset=iso-8859-1"> > </head> > > Here's code just sticking in a flag when meta charset's been seen. Committed a slightly modified version. Please check. -- Cheers Jorge.-

March 16, 2008

multiple-scan images consume a lot of CPU

by Johannes.Hofmann＠gmx.de

On Sat, Mar 15, 2008 at 11:46:59PM +0000, place wrote: > Johannes wrote: > > On Sat, Mar 15, 2008 at 10:16:09PM +0000, place wrote: > > > Johannes wrote: > > > > So as the "TODO" comment in jpeg.c already suggests, we need some > > > > way to switch off multiple-scan when the image is readily available > > > > either from cache, from disk, or from a fast network connection. > > > > > > > > I think some sort of rate limiting would be best that restricts > > > > rescans to - say - once a second. > > > That does not quite work for smaller images. The threshhold would > > need to depend somehow on the total size of the image. > > Do you encounter them much? I was hoping it was too rare to care about. Forget about this comment for now. Your patch below works great for me. I was seeing the problem for example on http://www.tourentipp.de When I went back to that page, it was pretty slow. Thanks, Johannes > > Looking at the bottom of Cache_process_queue(), maybe clients could be > taught to understand CA_Close in place of the last CA_Send for an entry. > Or some interface to get our hands on the cache entry's CA_GotData flag. > I don't know; Jorge will know better. > > > > And I get "Improper call to JPEG library in state 205" but that > > should be easily avoidable. > > Sorry, I was in a bit of a hurry at the time, and I don't have any > multiple scan jpegs now to try it on (could you point me to some?) > > It should have been something more like > > diff -pur dillo2/src/jpeg.c dillo2-cur/src/jpeg.c > --- dillo2/src/jpeg.c 2008-01-16 02:57:32.000000000 +0000 > +++ dillo2-cur/src/jpeg.c 2008-03-15 23:24:21.000000000 +0000 > @@ -293,7 +293,7 @@ static void Jpeg_write(DilloJpeg *jpeg, > * when an image arrives slowly, but should not be used to redisplay > * cached images. > */ > - if (jpeg_has_multiple_scans(&jpeg->cinfo)) > + if ((BufSize < 2000) && jpeg_has_multiple_scans(&jpeg->cinfo)) > jpeg->cinfo.buffered_image = TRUE; > > a_Dicache_set_parms(jpeg->url, jpeg->version, jpeg->Image, > @@ -309,7 +309,7 @@ static void Jpeg_write(DilloJpeg *jpeg, > /* decompression step 5 (see libjpeg.doc) */ > if (jpeg_start_decompress(&(jpeg->cinfo))) { > jpeg->y = 0; > - jpeg->state = jpeg_has_multiple_scans(&jpeg->cinfo) ? > + jpeg->state = jpeg->cinfo.buffered_image ? > DILLO_JPEG_READ_BEGIN_SCAN : DILLO_JPEG_READ_IN_SCAN; > } > } > @@ -355,7 +355,7 @@ static void Jpeg_write(DilloJpeg *jpeg, > > if (jpeg->y == jpeg->cinfo.image_height) { > /* end of scan */ > - if (!jpeg_has_multiple_scans(&jpeg->cinfo)) { > + if (!jpeg->cinfo.buffered_image) { > jpeg->state = DILLO_JPEG_DONE; > break; > } else { > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

March 16, 2008

multiple-scan images consume a lot of CPU

by place＠gobigwest.com

Johannes wrote: > On Sat, Mar 15, 2008 at 10:16:09PM +0000, place wrote: > > Johannes wrote: > > > So as the "TODO" comment in jpeg.c already suggests, we need some > > > way to switch off multiple-scan when the image is readily available > > > either from cache, from disk, or from a fast network connection. > > > > > > I think some sort of rate limiting would be best that restricts > > > rescans to - say - once a second. > That does not quite work for smaller images. The threshhold would > need to depend somehow on the total size of the image. Do you encounter them much? I was hoping it was too rare to care about. Looking at the bottom of Cache_process_queue(), maybe clients could be taught to understand CA_Close in place of the last CA_Send for an entry. Or some interface to get our hands on the cache entry's CA_GotData flag. I don't know; Jorge will know better. > And I get "Improper call to JPEG library in state 205" but that > should be easily avoidable. Sorry, I was in a bit of a hurry at the time, and I don't have any multiple scan jpegs now to try it on (could you point me to some?) It should have been something more like diff -pur dillo2/src/jpeg.c dillo2-cur/src/jpeg.c --- dillo2/src/jpeg.c 2008-01-16 02:57:32.000000000 +0000 +++ dillo2-cur/src/jpeg.c 2008-03-15 23:24:21.000000000 +0000 @@ -293,7 +293,7 @@ static void Jpeg_write(DilloJpeg *jpeg, * when an image arrives slowly, but should not be used to redisplay * cached images. */ - if (jpeg_has_multiple_scans(&jpeg->cinfo)) + if ((BufSize < 2000) && jpeg_has_multiple_scans(&jpeg->cinfo)) jpeg->cinfo.buffered_image = TRUE; a_Dicache_set_parms(jpeg->url, jpeg->version, jpeg->Image, @@ -309,7 +309,7 @@ static void Jpeg_write(DilloJpeg *jpeg, /* decompression step 5 (see libjpeg.doc) */ if (jpeg_start_decompress(&(jpeg->cinfo))) { jpeg->y = 0; - jpeg->state = jpeg_has_multiple_scans(&jpeg->cinfo) ? + jpeg->state = jpeg->cinfo.buffered_image ? DILLO_JPEG_READ_BEGIN_SCAN : DILLO_JPEG_READ_IN_SCAN; } } @@ -355,7 +355,7 @@ static void Jpeg_write(DilloJpeg *jpeg, if (jpeg->y == jpeg->cinfo.image_height) { /* end of scan */ - if (!jpeg_has_multiple_scans(&jpeg->cinfo)) { + if (!jpeg->cinfo.buffered_image) { jpeg->state = DILLO_JPEG_DONE; break; } else {

March 16, 2008

multiple-scan images consume a lot of CPU

by Johannes.Hofmann＠gmx.de

On Sat, Mar 15, 2008 at 10:16:09PM +0000, place wrote: > Johannes wrote: > > I really like the multiple-scan image feature added to dillo > > recently, but it uses quite some CPU and makes it drag slow when > > going back and forth on pages with a lot of images. > > > > So as the "TODO" comment in jpeg.c already suggests, we need some > > way to switch off multiple-scan when the image is readily available > > either from cache, from disk, or from a fast network connection. > > > > I think some sort of rate limiting would be best that restricts > > rescans to - say - once a second. > > > > What do you think? > > Just as a quick experiment, would something like the following do much good? > > diff -pur dillo2/src/jpeg.c dillo2-cur/src/jpeg.c > --- dillo2/src/jpeg.c 2008-01-16 02:57:32.000000000 +0000 > +++ dillo2-cur/src/jpeg.c 2008-03-15 22:10:59.000000000 +0000 > @@ -293,7 +293,7 @@ static void Jpeg_write(DilloJpeg *jpeg, > * when an image arrives slowly, but should not be used to redisplay > * cached images. > */ > - if (jpeg_has_multiple_scans(&jpeg->cinfo)) > + if ((BufSize < 2000) && jpeg_has_multiple_scans(&jpeg->cinfo)) > jpeg->cinfo.buffered_image = TRUE; > > a_Dicache_set_parms(jpeg->url, jpeg->version, jpeg->Image, > That does not quite work for smaller images. The threshhold would need to depend somehow on the total size of the image. And I get "Improper call to JPEG library in state 205" but that should be easily avoidable. Cheers, Johannes

March 16, 2008

multiple-scan images consume a lot of CPU

by place＠gobigwest.com

Johannes wrote: > I really like the multiple-scan image feature added to dillo > recently, but it uses quite some CPU and makes it drag slow when > going back and forth on pages with a lot of images. > > So as the "TODO" comment in jpeg.c already suggests, we need some > way to switch off multiple-scan when the image is readily available > either from cache, from disk, or from a fast network connection. > > I think some sort of rate limiting would be best that restricts > rescans to - say - once a second. > > What do you think? Just as a quick experiment, would something like the following do much good? diff -pur dillo2/src/jpeg.c dillo2-cur/src/jpeg.c --- dillo2/src/jpeg.c 2008-01-16 02:57:32.000000000 +0000 +++ dillo2-cur/src/jpeg.c 2008-03-15 22:10:59.000000000 +0000 @@ -293,7 +293,7 @@ static void Jpeg_write(DilloJpeg *jpeg, * when an image arrives slowly, but should not be used to redisplay * cached images. */ - if (jpeg_has_multiple_scans(&jpeg->cinfo)) + if ((BufSize < 2000) && jpeg_has_multiple_scans(&jpeg->cinfo)) jpeg->cinfo.buffered_image = TRUE; a_Dicache_set_parms(jpeg->url, jpeg->version, jpeg->Image,

March 15, 2008

multiple-scan images consume a lot of CPU

by Johannes.Hofmann＠gmx.de

Hi, I really like the multiple-scan image feature added to dillo recently, but it uses quite some CPU and makes it drag slow when going back and forth on pages with a lot of images. So as the "TODO" comment in jpeg.c already suggests, we need some way to switch off multiple-scan when the image is readily available either from cache, from disk, or from a fast network connection. I think some sort of rate limiting would be best that restricts rescans to - say - once a second. What do you think? Cheers, Johannes

March 15, 2008

patch: multipart/form-data CRLF

by place＠gobigwest.com

Happened to notice in the RFC that multipart types must use CRLF between body parts. PS It was a bit annoying to figure out that http.c needed to be changed, which suggests that it would have been better for me to store the boundary string in DilloUrl somewhere after all.

March 15, 2008

https plugin status

by onepoint＠starurchin.org

On Sat, Mar 15, 2008 at 03:31:52PM -0400, Jorge Arellano Cid wrote: > > [Jeremey wrote] > > Or maybe Capi_url_uses_dpi() should be checking for "https" and > > *not* adding the "proto." prefix? > > "proto.https" is the right patch. OK, what about my patch to redirect MSG debugging messages from stdout to stderr? Is that correct? Regards, Jeremy Henty

March 15, 2008

[patch] don't restart scanning from start in Html_parse_entities ()

by Johannes.Hofmann＠gmx.de

Hi, below is a small optinization to Html_parse_entities (). Cheers, Johannes diff -r bd486ec2a522 src/html.cc --- a/src/html.cc Sat Mar 15 19:41:01 2008 +0100 +++ b/src/html.cc Sat Mar 15 20:23:03 2008 +0100 @@ -1397,13 +1397,14 @@ static char * { const char *esc_set = "&\xE2\xC2"; char *new_str, buf[4]; - int i, j, k, n, isocode, entsize; + int i, j, k, n, s, isocode, entsize; new_str = dStrndup(token, toksize); - if (new_str[strcspn(new_str, esc_set)] == 0) + s = strcspn(new_str, esc_set); + if (new_str[s] == 0) return new_str; - for (i = j = 0; i < toksize; i++) { + for (i = j = s; i < toksize; i++) { if (token[i] == '&' && (isocode = Html_parse_entity(html, token+i, toksize-i, &entsize)) >= 0) {

March 15, 2008

[patch] further reduce redraws from resizing tables

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Fri, Mar 14, 2008 at 06:53:08PM -0400, Jorge Arellano Cid wrote: > Hi Johannes, > > On Tue, Mar 11, 2008 at 07:27:01PM +0100, Johannes Hofmann wrote: > > Hi, > > > > below is another patch to reduce the redraws caused by resizing > > tables. A new method Layout::queueDrawExcept(), that requests the > > drawing of a rectangle except another rectangle is added. > > It is then used in widget.cc to redraw the area that was previously > > occupied by a widget, but is no longer occupied after a resize or move. > > This makes it possible to redraw less when a table resizes. > > All in all it should reduce the flicker a bit when loading table > > based pages. > > On the topic of reducing the flicker, I'm far of an expert and > please correct me if I'm wrong. AFAIU, the current design draws > the background color before the widget content. > > This is: if you have an html page as big table, in dillo, it > will become a table inside a textblock. When the textblock is > asked to redraw, it will _erase_ the table with its background > color and ask its child (the table) to redraw. Causing flicker. Yes, that's true. In addition, before anything is drawn, the rectangle to be drawn is already cleared with the background color in FltkViewBase::draw() (the fillrect () calls). > > If this is true, a big gain could come from a different > approach: just draw the surroundings of the widgets and ask the > child widgets to redraw. > > This way widgets aren't erased beforehand, and can also decide > not to redraw themselves when nothing has changed. > > I have worked a bit on this idea, and the attached patch mocks > the idea hackishly. It draws the "padding" area of the CSS box > (see the picture in namespacedw_1_1core_1_1style.html in dw docs) > > Please give it a review and share your comments, > corrections and thoughts. I've been thinking about something similar as well, but I don't think it will work out generally. The main problem is text drawing and maybe transparent widgets (don't know whether they exist already). Anyway, for drawing text, you need to erase the area first. Just comment out the fillrect () calls in FltkViewBase::draw() to see what I mean :-) Therefore, we will always have flicker, when drawing text. The good news is that all the flicker can be avoided easily with some double buffering technique. And from dillo1 we even know that this is not necessarily slow :-) So for me the flicker itself is not that much of a problem. It may be an indicator for unnecessary redraws, which should be avoided to save CPU power. But I think current cvs is already pretty good in this regard. So I would propose to start to think about efficient double buffering similar to what I had posted in http://lists.auriga.wearlab.de/pipermail/dillo-dev/2007-November/003379.html but platform independent using fltk2 support. Cheers, Johannes

March 15, 2008

[PATCH]: Fixing https step 1: Have a basic dpi dialog window working again

by Christian.Kellermann＠nefkom.net

Hi Jorge, * Jorge Arellano Cid <jcid(a)dillo.org> [080315 18:58]: > Sorry for the late answer, but I've had little spare time, > and several topics to answer. > > Probably you have already read: > > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2007-September/003211.ht… > > an got some info from there. Yes, thanks for the hint, it was insightful. I have spend a few thoughts on the SSL issue and I'd like to hear your opinion on it. The most work that still needs to be done is to handle certificates and the user interaction required to make it usable. The user needs to add trust values to certificates and to add or remove them offline. I think this can fit well into a server dpi. Adding and deleting bookmarks could be done similar to handling bookmarks. Which might be a bit rough but is independent on fltk widgets. I do think that we already have enough dialog types in dillo. Hard coding the certificate handling would not make the situation any better. Also I can imagine this plugin to handle client certificates which I do believe will become a more common requirement for certain applications in the future. Adding secure storage capabilities will be easy. Also people will have the chance to write some "bridging" plugin that extracts the needed data from existing storage sources elsewhere, i.e. certificate servers,... Handling this all internally means that we put functionality into dillo that are needed for, but basically have nothing to do with browsing. As I have grasped the spirit of this project this may not be the way to go. A nice thing about handling https internally is the opportunity to reuse an established connection for more than one request, which might speed up transfers significantly. But on the other hand couldn't this be done by dpid for all filter plugins? Dpid can keep them alive as long as the following requests belong to the same URL, then closing the connection after a timeout? I am sorry if this has been already decided on before. These thoughts were rumaging aroung my head all day now... Kind regards, Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

March 15, 2008

https plugin status

by jcid＠dillo.org

Hi, Just a follow up on https dpi: > [place wrote] > It appears that Capi_dpi_build_cmd() needs to test for "proto.https" instead > of "https"... Yes this is a bug from the latest big dpi upgrade (generic dpi protos). > [Jeremey wrote] > Or maybe Capi_url_uses_dpi() should be checking for "https" and *not* > adding the "proto." prefix? "proto.https" is the right patch. > [Christian wrote] > But what is supposed to be working atm? Really basic, if you can see: https://www.rapidssl.com/test/rapidssl.htm that's all. BTW, with place's patch, I can also see: https://www.ccc.de > [Jeremey wrote] > Getting https working would greatly reduce the number of times I run > Firefox! I thought many https sites needed javascript to work. _Please_ correct me if I'm wrong. :-) > [...] With regard to the missing dialog function, you may get a very good idea by looking at its implementation in dillo-0.8.6. That's what I'd do to answer if I had the time now. -- Cheers Jorge.-

March 15, 2008

[PATCH]: Fixing https step 1: Have a basic dpi dialog window working again

by jcid＠dillo.org

Hi Christian, Sorry for the late answer, but I've had little spare time, and several topics to answer. Probably you have already read: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2007-September/003211.ht… an got some info from there. On Sat, Mar 15, 2008 at 02:02:07PM +0100, Christian Kellermann wrote: > * Christian Kellermann <Christian.Kellermann(a)nefkom.net> [080315 09:49]: > > Dear list, > > > > In order to fix the https plugin I have stumbled upon the fact, > > that the former dialog code seems to be removed from cvs. To see > > what's goign on further down the code I have added a basic Yes/No > > popup using the existing a_Dialog_choice3 function. For this the > > numbering of the buttons have changed also in https. Dialogs with > > more than two alternatives will have the additional choices dropped > > silently. This is good for now but I really like to have it done > > right. Which function should get used instead of a_Dialog_choice3? > > > > Also what's the real purpose of http_request? At the moment I cheat > > and set it to url in case it is empty. Which value is to be expected > > when calling the document root in a URL? "/"? "/index.html"? or am > > I getting this all wrong? > > > > Whith this patch I can bypass the "certificate could not get verified" > > case but not much further. Also cancelling the dialog seems to leave > > some data behind, another call of https URLs won't do anything. But > > this is a bit better than it has been before... > > > > I am not sure whether I should stop beating this dead horse or > > continue. What's your advice? > > > > Ignore the http_request part I figured it out. > > Ok, I have changed the proto comparison from "https" -> "proto.https" > and I am able to view https sites again. This module still needs a > lot of cleanup. As a next step I want to implement simple certificate > caching so accepted certificates won't get prompted again. This > will be memory only at first, making the certificate valid (or > invalid) as long as the dpid lives. > > The updated patch is attached below. A long time ago, browsing was mainly fetching pages and images. It made a lot of sense to use an external tool (as wget) to grab https pages. Implementing this idea with dpi was also simple. Now, it may be not the case. You have to keep track of certificates, sessions, sometimes keep an open connection, etc. Years ago SSL wasn't widespread, today is an everyday need, so it may make sense to consider having it inside dillo. It can take some design time at the beginning but will be easier to maintain and extend than to have it living in an external dpi. Developers is what we need, so if you want to work on https, you're more than welcome. Lack of manpower is our biggest problem! "place" implemented gzip decoding in dillo2, he may help you with ideas on how to add an extra layer/decoding-stage for SSL. (With regard to your specific questions about https, you'll have to wait some time until I can look at it again in depth. IIRC there was a five option dialog requested through dpip that sent the answer back on what to do. It was removed from the code while porting, delayed for future implementation). Again, my suggestion is to consider an internal implementation. -- Cheers Jorge.-

March 15, 2008

[PATCH]: a_Dpiapi_dialog should call a_Dialog_choice3 with 3 parameters

by onepoint＠starurchin.org

On Sat, Mar 15, 2008 at 02:04:32PM +0100, Christian Kellermann wrote: > Ah thanks! I add it to step 2 :) In the meantime you need to apply > this again to my updated version of step 1. OK, here's an updated fix for your updated step 1. Regards, Jeremy Henty

March 15, 2008

[PATCH]: a_Dpiapi_dialog should call a_Dialog_choice3 with 3 parameters

by Christian.Kellermann＠nefkom.net

* Jeremy Henty <onepoint(a)starurchin.org> [080315 13:54]: > > a_Dpiapi_dialog() calls a_Dialog_choice3() with 2 parameters instead > of 3. This causes the dialog to pop up a third button with a garbage > label, and valgrind reports 'Conditional jump or move depends on > uninitialised value(s)' from inside FLTK. Patch attached. > > This bug slipped through because dpiapi.c does not include dialog.hh > to get the prototype of a_Dialog_choice3() . I'm not sure how to fix > this: should a C source file be including a C++ header? If not, how > else can dpiapi.c get the prototype? > Ah thanks! I add it to step 2 :) In the meantime you need to apply this again to my updated version of step 1. You were faster than me :) Kind regards, Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

March 15, 2008

[PATCH]: Fixing https step 1: Have a basic dpi dialog window working again

by Christian.Kellermann＠nefkom.net

Skipped content of type multipart/mixed

March 15, 2008

[PATCH]: a_Dpiapi_dialog should call a_Dialog_choice3 with 3 parameters

by onepoint＠starurchin.org

To clarify, this patch is a fix to Christian Kellermann's https patch, so it naturally depends on it. Jeremy Henty

March 15, 2008

[PATCH]: Fixing https step 1: Have a basic dpi dialog window working again

by onepoint＠starurchin.org

On Sat, Mar 15, 2008 at 09:45:40AM +0100, Christian Kellermann wrote: > I am not sure whether I should stop beating this dead horse or > continue. What's your advice? I would really like to see this working. What's the next step? Regards, Jeremy Henty

March 15, 2008

[PATCH]: a_Dpiapi_dialog should call a_Dialog_choice3 with 3 parameters

by onepoint＠starurchin.org

a_Dpiapi_dialog() calls a_Dialog_choice3() with 2 parameters instead of 3. This causes the dialog to pop up a third button with a garbage label, and valgrind reports 'Conditional jump or move depends on uninitialised value(s)' from inside FLTK. Patch attached. This bug slipped through because dpiapi.c does not include dialog.hh to get the prototype of a_Dialog_choice3() . I'm not sure how to fix this: should a C source file be including a C++ header? If not, how else can dpiapi.c get the prototype? Regards, Jeremy Henty

March 15, 2008

[PATCH]: Fixing https step 1: Have a basic dpi dialog window working again

by Christian.Kellermann＠nefkom.net

Skipped content of type multipart/mixed

March 15, 2008

https plugin status

by Christian.Kellermann＠nefkom.net

Hi, nevermind the last post the dpid_tag _is_ syntactically correct. Why should http_query be missing though? Shouldn't it at least be the same as url? Kind regards, Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

March 15, 2008

https plugin status

by Christian.Kellermann＠nefkom.net

* Jeremy Henty <onepoint(a)starurchin.org> [080315 05:58]: > On Sat, Mar 15, 2008 at 01:22:09AM +0000, Jeremy Henty (ie. me) wrote: > > > I was wrong, the https filter dpi *is* starting. But, its debugging > > messages don't appear because it sends them to stdout, which dpid > > redirects to the DPI socket. This feels ... somehow ... wrong. > > And so it is! (Patch submitted in a new thread.) After redirecting > the debugging messages to stderr I see: > > [https dpi]: {In https.filter.dpi} > [https dpi]: ***Value of cmd, url or http_query is NULL - cannot continue > [https dpi]: { exiting https.dpi} > If you add an additional MSG output you see something like this: [https dpi]: {In https.filter.dpi} [https dpi]: dpip_tag <cmd='open_url' url='https://www.ccc.de' '> [https dpi]: ***Value of cmd, url or http_query is NULL - cannot continue [https dpi]: { exiting https.dpi} dpid_tag looks like there is a missing '. I added Index: dpi/https.c =================================================================== RCS file: /sfhome/cvs/dillo/dillo2/dpi/https.c,v retrieving revision 1.1.1.1 diff -b -u -p -r1.1.1.1 https.c --- dpi/https.c 6 Oct 2007 22:36:34 -0000 1.1.1.1 +++ dpi/https.c 15 Mar 2008 07:51:29 -0000 @@ -191,6 +191,9 @@ static void yes_ssl_support(void) /*Get the network address and command to be used*/ dpip_tag = sock_handler_read(sh); + + MSG("dpip_tag %s\n",dpip_tag); + cmd = a_Dpip_get_attr(dpip_tag, strlen(dpip_tag), "cmd"); url = a_Dpip_get_attr(dpip_tag, strlen(dpip_tag), "url"); http_query = a_Dpip_get_attr(dpip_tag, strlen(dpip_tag), "query"); I am not sure whether this is really save, is this tag \0 terminated? Nonetheless something is lost on the way... Kind regards, Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

March 15, 2008

https plugin status

by onepoint＠starurchin.org

On Sat, Mar 15, 2008 at 02:18:27AM +0000, place wrote: > It appears that Capi_dpi_build_cmd() needs to test for "proto.https" > instead of "https"... Or maybe Capi_url_uses_dpi() should be checking for "https" and *not* adding the "proto." prefix? I'm just guessing here, I'm still figuring out this code. Regards, Jeremy Henty

March 15, 2008

https plugin status

by place＠gobigwest.com

Jeremy wrote: > On Sat, Mar 15, 2008 at 01:22:09AM +0000, Jeremy Henty (ie. me) wrote: > > > I was wrong, the https filter dpi *is* starting. But, its debugging > > messages don't appear because it sends them to stdout, which dpid > > redirects to the DPI socket. This feels ... somehow ... wrong. > > And so it is! (Patch submitted in a new thread.) After redirecting > the debugging messages to stderr I see: > > [https dpi]: {In https.filter.dpi} > [https dpi]: ***Value of cmd, url or http_query is NULL - cannot continue > [https dpi]: { exiting https.dpi} > > which at least gives some idea of what is going wrong. It appears that Capi_dpi_build_cmd() needs to test for "proto.https" instead of "https"...

March 15, 2008

https plugin status

by onepoint＠starurchin.org

On Sat, Mar 15, 2008 at 01:22:09AM +0000, Jeremy Henty (ie. me) wrote: > I was wrong, the https filter dpi *is* starting. But, its debugging > messages don't appear because it sends them to stdout, which dpid > redirects to the DPI socket. This feels ... somehow ... wrong. And so it is! (Patch submitted in a new thread.) After redirecting the debugging messages to stderr I see: [https dpi]: {In https.filter.dpi} [https dpi]: ***Value of cmd, url or http_query is NULL - cannot continue [https dpi]: { exiting https.dpi} which at least gives some idea of what is going wrong. Jeremy Henty

March 15, 2008

[PATCH]: send the https dpi plugin debug messages to the right place

by onepoint＠starurchin.org

The https DPI plugin sends its debug messages to stdin. This is wrong because the DPI daemon dups the plugin's stdin to the DPI socket. This patch redirects the debug messages to stderr. Jeremy Henty

March 15, 2008

https plugin status

by onepoint＠starurchin.org

On Fri, Mar 14, 2008 at 11:35:38PM +0000, Jeremy Henty (ie. me) wrote: > ... I can see the CCC setting up tearing down the IO links, so it > looks as though the dillo process is talking to something, and > getting something sensible from it. But AFAICT the https filter dpi > isn't even starting (it should dump some startup messages to stdout > which I'm not seeing). I was wrong, the https filter dpi *is* starting. But, its debugging messages don't appear because it sends them to stdout, which dpid redirects to the DPI socket. This feels ... somehow ... wrong. Jeremy Henty

March 15, 2008

https plugin status

by onepoint＠starurchin.org

On Fri, Mar 14, 2008 at 07:19:45PM +0100, Christian Kellermann wrote: > Dear list, > > is the https plugin supposed to work? My take on the status of https is that it's currently my biggest itch! :-) I've been gdb-ing dillo-fltk (looking at it from the other end from you, as it were), and I can see the CCC setting up tearing down the IO links, so it looks as though the dillo process is talking to something, and getting something sensible from it. But AFAICT the https filter dpi isn't even starting (it should dump some startup messages to stdout which I'm not seeing). Like you I'd appreciate some guidance from those wiser than myself. Getting https working would greatly reduce the number of times I run Firefox! Regards, Jeremy Henty

March 15, 2008

libiconv fix for OpenBSD

by Christian.Kellermann＠nefkom.net

* Jorge Arellano Cid <jcid(a)dillo.org> [080314 21:40]: > > Committed, but in two places! Yeah I have seen it. Why is the same code duplicated? Once should be enough. My original patch contained such one instance of the tests... Kind regards, Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

March 15, 2008

[patch] further reduce redraws from resizing tables

by jcid＠dillo.org

Hi Johannes, On Tue, Mar 11, 2008 at 07:27:01PM +0100, Johannes Hofmann wrote: > Hi, > > below is another patch to reduce the redraws caused by resizing > tables. A new method Layout::queueDrawExcept(), that requests the > drawing of a rectangle except another rectangle is added. > It is then used in widget.cc to redraw the area that was previously > occupied by a widget, but is no longer occupied after a resize or move. > This makes it possible to redraw less when a table resizes. > All in all it should reduce the flicker a bit when loading table > based pages. On the topic of reducing the flicker, I'm far of an expert and please correct me if I'm wrong. AFAIU, the current design draws the background color before the widget content. This is: if you have an html page as big table, in dillo, it will become a table inside a textblock. When the textblock is asked to redraw, it will _erase_ the table with its background color and ask its child (the table) to redraw. Causing flicker. If this is true, a big gain could come from a different approach: just draw the surroundings of the widgets and ask the child widgets to redraw. This way widgets aren't erased beforehand, and can also decide not to redraw themselves when nothing has changed. I have worked a bit on this idea, and the attached patch mocks the idea hackishly. It draws the "padding" area of the CSS box (see the picture in namespacedw_1_1core_1_1style.html in dw docs) Please give it a review and share your comments, corrections and thoughts. -- Cheers Jorge.-

March 14, 2008

patch: meta charset changes decoder

by place＠gobigwest.com

Johannes wrote: > On Thu, Mar 13, 2008 at 10:49:47AM -0400, Jorge Arellano Cid wrote: > > Hi, > > > > On Fri, Mar 07, 2008 at 06:17:17AM +0000, place wrote: > > > This is no sort of proper fix whatsoever, but I was tired > > > of seeing the "would set charset" message. It's actually > > > surprisingly useful for remote files, since they're generally > > > still at the javascript-and-css point at the end of the first packet. > > > > In CVS there is a new approach that restarts parsing the whole page. > > It works with local/remote files, and page title. Please test it. > > Not 100% sure if it's this change, but since recently dillo-fltk > loops for me on http://www.ebay.com: > > META Content-Type changes charset to: ISO-8859-1 > Nav_open_url: new url='http://www.ebay.com/' > HTTP Content-Type gave charset as: ISO-8859-1 > META Content-Type gave charset as: ISO-8859-1 > FltkViewBase::drawTotal > META Content-Type changes charset to: Cp1252 > Nav_open_url: new url='http://www.ebay.com/' > HTTP Content-Type gave charset as: ISO-8859-1 > META Content-Type gave charset as: Cp1252 > FltkViewBase::drawTotal > META Content-Type changes charset to: ISO-8859-1 > Nav_open_url: new url='http://www.ebay.com/' > HTTP Content-Type gave charset as: ISO-8859-1 > META Content-Type gave charset as: ISO-8859-1 > FltkViewBase::drawTotal I should have made it clearer that my little patch from a day ago was intended to fix such looping.

March 14, 2008

patch: meta charset changes decoder

by Johannes.Hofmann＠gmx.de

Hi, On Thu, Mar 13, 2008 at 10:49:47AM -0400, Jorge Arellano Cid wrote: > Hi, > > On Fri, Mar 07, 2008 at 06:17:17AM +0000, place wrote: > > This is no sort of proper fix whatsoever, but I was tired > > of seeing the "would set charset" message. It's actually > > surprisingly useful for remote files, since they're generally > > still at the javascript-and-css point at the end of the first packet. > > In CVS there is a new approach that restarts parsing the whole page. > It works with local/remote files, and page title. Please test it. Not 100% sure if it's this change, but since recently dillo-fltk loops for me on http://www.ebay.com: META Content-Type changes charset to: ISO-8859-1 Nav_open_url: new url='http://www.ebay.com/' HTTP Content-Type gave charset as: ISO-8859-1 META Content-Type gave charset as: ISO-8859-1 FltkViewBase::drawTotal META Content-Type changes charset to: Cp1252 Nav_open_url: new url='http://www.ebay.com/' HTTP Content-Type gave charset as: ISO-8859-1 META Content-Type gave charset as: Cp1252 FltkViewBase::drawTotal META Content-Type changes charset to: ISO-8859-1 Nav_open_url: new url='http://www.ebay.com/' HTTP Content-Type gave charset as: ISO-8859-1 META Content-Type gave charset as: ISO-8859-1 FltkViewBase::drawTotal .... Cheers, Johannes

March 14, 2008

libiconv fix for OpenBSD

by jcid＠dillo.org

On Fri, Mar 14, 2008 at 07:34:29PM +0100, Christian Kellermann wrote: > * Jorge Arellano Cid <jcid(a)dillo.org> [080314 19:11]: > > Committed. > > > > (now, we'll wait to see if it works OK for everybody else ;). > > Unfortunately this introduces -Werror and thus may break the build. This is due to a silly typo. > My apologies... > > Index: configure.in > =================================================================== > RCS file: /sfhome/cvs/dillo/dillo2/configure.in,v > retrieving revision 1.7 > diff -b -u -p -r1.7 configure.in > --- configure.in 14 Mar 2008 18:04:19 -0000 1.7 > +++ configure.in 14 Mar 2008 18:44:05 -0000 > @@ -344,7 +344,7 @@ if test "x$iconv_ok" = "xyes"; then > ], > iconv_old=yes,iconv_old=no) > LIBS="$old_libs" > - CLFAGS="$old_cflags" > + CFLAGS="$old_cflags" > > if test "x$iconv_old" = "xyes"; then > AC_DEFINE([inbuf_t], [const char], [Use const char pointers for older libiconv]) > > > Thanks, > > Christian Committed, but in two places! -- Cheers Jorge.-

March 14, 2008

libiconv fix for OpenBSD

by Christian.Kellermann＠nefkom.net

* Jorge Arellano Cid <jcid(a)dillo.org> [080314 19:11]: > Committed. > > (now, we'll wait to see if it works OK for everybody else ;). Unfortunately this introduces -Werror and thus may break the build. This is due to a silly typo. My apologies... Index: configure.in =================================================================== RCS file: /sfhome/cvs/dillo/dillo2/configure.in,v retrieving revision 1.7 diff -b -u -p -r1.7 configure.in --- configure.in 14 Mar 2008 18:04:19 -0000 1.7 +++ configure.in 14 Mar 2008 18:44:05 -0000 @@ -344,7 +344,7 @@ if test "x$iconv_ok" = "xyes"; then ], iconv_old=yes,iconv_old=no) LIBS="$old_libs" - CLFAGS="$old_cflags" + CFLAGS="$old_cflags" if test "x$iconv_old" = "xyes"; then AC_DEFINE([inbuf_t], [const char], [Use const char pointers for older libiconv]) Thanks, Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

March 14, 2008

https plugin status

by Christian.Kellermann＠nefkom.net

Dear list, is the https plugin supposed to work? Whenever I select a https URL dpid gets started but nothing happens whatsoever. I do have SSL enabled and all. I am aware that there is some work needed and that https support is considered as very basic. But what is supposed to be working atm? It is easier to fix bugs if you know what it should look like... Thanks, Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

March 14, 2008

libiconv fix for OpenBSD

by jcid＠dillo.org

On Fri, Mar 14, 2008 at 05:52:05PM +0100, Christian Kellermann wrote: > * Jorge Arellano Cid <jcid(a)dillo.org> [080314 16:06]: > > > I hope this does not break other systems. > > > > Unfortunately it does. > > > > You can try this in your system. > > (but first check a simple "#define inbuf_t const char" in config.h, > > plus the respective patch). > > Thanks for the clarification! This is my first stab at autoconf > so please bear with me. I have attached a patch that addresses > this issue. I am not so sure if it handles the case of the newer > interface well. Obvoiously I cannot test it. > Could someone else give this a try? > > Thanks again, It works here! Committed. (now, we'll wait to see if it works OK for everybody else ;). -- Cheers Jorge.-

March 14, 2008

libiconv fix for OpenBSD

by Christian.Kellermann＠nefkom.net

Skipped content of type multipart/mixed

March 14, 2008

libiconv fix for OpenBSD

by jcid＠dillo.org

On Thu, Mar 13, 2008 at 10:35:23PM +0100, Christian Kellermann wrote: > Dear List, > > let me again thank you for your great efforts! One minor thing I > stumbled upon today's update: My System has the following iconv > signature: size_t iconv (iconv_t cd, > const char* * inbuf, size_t * inbytesleft, > char* * outbuf, size_t * outbytesleft); > > I therefore need something like the following to make dillo compile > (an work) again: > > Index: src/html.cc > =================================================================== > RCS file: /sfhome/cvs/dillo/dillo2/src/html.cc,v > retrieving revision 1.48 > diff -b -u -p -r1.48 html.cc > --- src/html.cc 13 Mar 2008 14:58:44 -0000 1.48 > +++ src/html.cc 13 Mar 2008 21:43:26 -0000 > @@ -3844,7 +3844,8 @@ static Dstr *Html_encode_text(iconv_t en > int rc = 0; > Dstr *output; > const int bufsize = 128; > - char *buffer, *inPtr, *outPtr; > + const char *inPtr; > + char *buffer, *outPtr; > size_t inLeft, outRoom; > bool bad_chars = false; You will also need to patch decode.c. > > I hope this does not break other systems. Unfortunately it does. Your system conforms to the old standard: http://www.opengroup.org/onlinepubs/007908799/xsh/iconv.html Glibc conforms to the new one: http://www.opengroup.org/onlinepubs/009695399/functions/iconv.html One way I see to overcome this in Dillo is to define an inbuf_t from autoconf, and to use it in html.cc and decode.cc. If configure.in checks for a longer program, like: #include <iconv.h> int main(void) { const char *inPtr; char *outPtr; size_t inLeft = 0, outRoom = 0; iconv_t encoder = iconv_open("ASCII", "UTF-8"); iconv(encoder, &inPtr, &inLeft, &outPtr, &outRoom); return 0; } using gcc -Werror, if it passes, #define inbuf_t const char You can try this in your system. (but first check a simple "#define inbuf_t const char" in config.h, plus the respective patch). -- Cheers Jorge.-

March 14, 2008

libiconv fix for OpenBSD

by Christian.Kellermann＠nefkom.net

Dear List, let me again thank you for your great efforts! One minor thing I stumbled upon today's update: My System has the following iconv signature: size_t iconv (iconv_t cd, const char* * inbuf, size_t * inbytesleft, char* * outbuf, size_t * outbytesleft); I therefore need something like the following to make dillo compile (an work) again: Index: src/html.cc =================================================================== RCS file: /sfhome/cvs/dillo/dillo2/src/html.cc,v retrieving revision 1.48 diff -b -u -p -r1.48 html.cc --- src/html.cc 13 Mar 2008 14:58:44 -0000 1.48 +++ src/html.cc 13 Mar 2008 21:43:26 -0000 @@ -3844,7 +3844,8 @@ static Dstr *Html_encode_text(iconv_t en int rc = 0; Dstr *output; const int bufsize = 128; - char *buffer, *inPtr, *outPtr; + const char *inPtr; + char *buffer, *outPtr; size_t inLeft, outRoom; bool bad_chars = false; I hope this does not break other systems. Kind regards, Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

March 13, 2008

[patch] don't allocate tagnames on stack

by Johannes.Hofmann＠gmx.de

Hi, here is another patch that avoids some malloc/free calls. Cheers, Johannes diff --git a/src/html.cc b/src/html.cc --- a/src/html.cc +++ b/src/html.cc @@ -194,7 +194,7 @@ struct _DilloLinkImage { }; struct _DilloHtmlState { - char *tag_name; + const char *tag_name; dw::core::style::Style *style, *table_cell_style; DilloHtmlParseMode parse_mode; DilloHtmlTableMode table_mode; @@ -815,7 +815,7 @@ DilloHtml::DilloHtml(BrowserWindow *p_bw stack = new misc::SimpleVector <DilloHtmlState> (16); stack->increase(); - stack->getRef(0)->tag_name = dStrdup("none"); + stack->getRef(0)->tag_name = "none"; stack->getRef(0)->style = NULL; stack->getRef(0)->table_cell_style = NULL; stack->getRef(0)->parse_mode = DILLO_HTML_PARSE_MODE_INIT; @@ -1014,7 +1014,6 @@ void DilloHtml::closeParser(int ClientKe Html_tag_cleanup_at_close(this, stack->getRef(si)->tag_idx); } } - dFree(stack->getRef(0)->tag_name); /* "none" */ (stack->getRef(0)->style)->unref (); /* template style */ delete (stack); @@ -1596,18 +1595,14 @@ static void Html_eventually_pop_dw(Dillo */ static void Html_push_tag(DilloHtml *html, int tag_idx) { - char *tagstr; int n_items; - - /* Save the element's name (no parameters) into tagstr. */ - tagstr = dStrdup(Tags[tag_idx].name); n_items = html->stack->size (); html->stack->increase (); /* We'll copy the former stack item and just change the tag and its index * instead of copying all fields except for tag. --Jcid */ *html->stack->getRef(n_items) = *html->stack->getRef(n_items - 1); - html->stack->getRef(n_items)->tag_name = tagstr; + html->stack->getRef(n_items)->tag_name = Tags[tag_idx].name; html->stack->getRef(n_items)->tag_idx = tag_idx; /* proper memory management, may be unref'd later */ (S_TOP(html)->style)->ref (); @@ -1635,7 +1630,6 @@ static void Html_real_pop_tag(DilloHtml (S_TOP(html)->style)->unref (); if (S_TOP(html)->table_cell_style) (S_TOP(html)->table_cell_style)->unref (); - dFree(S_TOP(html)->tag_name); hand_over_break = S_TOP(html)->hand_over_break; html->stack->setSize (html->stack->size() - 1); Html_eventually_pop_dw(html, hand_over_break); @@ -5582,7 +5576,7 @@ static int Html_write_raw(DilloHtml *htm DILLO_HTML_PARSE_MODE_VERBATIM) { /* Non HTML code here, let's skip until closing tag */ do { - char *tag = S_TOP(html)->tag_name; + const char *tag = S_TOP(html)->tag_name; buf_index += strcspn(buf + buf_index, "<"); if (buf_index + (int)strlen(tag) + 3 > bufsize) { buf_index = bufsize;

March 13, 2008

Re: patch: reorder headers in query string

by jcid＠dillo.org

On Thu, Mar 13, 2008 at 04:42:04PM +0000, place wrote: > > It'd be good to keep the suggested ordering then. > > Attached. Committed. -- Cheers Jorge.-

March 13, 2008

patch: Re: [Dillo-dev] patch: meta charset changes decoder

by place＠gobigwest.com

Jorge wrote: > On Fri, Mar 07, 2008 at 06:17:17AM +0000, place wrote: > > This is no sort of proper fix whatsoever, but I was tired > > of seeing the "would set charset" message. It's actually > > surprisingly useful for remote files, since they're generally > > still at the javascript-and-css point at the end of the first packet. > > In CVS there is a new approach that restarts parsing the whole page. > It works with local/remote files, and page title. Please test it. In the past, I've encountered pages that go <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> <meta http-equiv="content-type" content="text/html; charset=iso-8859-1"> </head> Here's code just sticking in a flag when meta charset's been seen.

March 13, 2008

[patch] reduce malloc/free use a bit

by jcid＠dillo.org

On Wed, Mar 12, 2008 at 09:26:52PM +0100, Johannes Hofmann wrote: > Hi, > > the patch below reduces the use of malloc/free a bit. For loading > http://www.w3.org/TR/xslt for example it reduces the number of calls > to dMalloc() from 76735 to 50478 (according to gprof). > > I have removed the SPCBuf member of html, as it seems not to be > used. Please correct me if I'm wrong or it is intended to be used > for in the future. Committed. It may remain from the old way of handling whitespace... -- Cheers Jorge.-

March 13, 2008

Re: patch: reorder headers in query string

by jcid＠dillo.org

On Wed, Mar 12, 2008 at 07:49:46PM +0000, place wrote: > Jorge wrote: > > On Wed, Mar 12, 2008 at 03:51:24PM +0000, place wrote: > > > My idea of what seems like a good ordering, for what that's worth :) > > > When I watch the headers, I always wonder why I didn't put Accept-Encoding > > > next to Accept-Charset, for one thing... > > > > AFAIR headers are ordered as they appear in the RFC. > > I'm not sure whether this is relevant, please check. > > Oh! Let's see. The RFC says: > > The order in which header fields with differing field names are > received is not significant. However, it is "good practice" to send > general-header fields first, followed by request-header or response- > header fields, and ending with the entity-header fields. > > Following that, placing them in order of appearance, yields: > > POST > > Connection > > Accept-Charset > Accept-Encoding > Host > Proxy-Authorization > Referer > User-Agent > > Content-Length > Content-Type > > Cookie > > GET > > Cache-Control > Connection > Pragma > > Accept-Charset > Accept-Encoding > Host > Proxy-Authorization > Referer > User-Agent > > Cookie > > Which is pretty close to what dillo has already if you don't count the headers > that I have added, since I never realized there was any ordering. Thanks for the info. I'd be good to keep the suggested ordering then. -- Cheers Jorge.-

March 13, 2008

patch: meta charset changes decoder

by jcid＠dillo.org

Hi, On Fri, Mar 07, 2008 at 06:17:17AM +0000, place wrote: > This is no sort of proper fix whatsoever, but I was tired > of seeing the "would set charset" message. It's actually > surprisingly useful for remote files, since they're generally > still at the javascript-and-css point at the end of the first packet. In CVS there is a new approach that restarts parsing the whole page. It works with local/remote files, and page title. Please test it. -- Cheers Jorge.-

March 13, 2008

Re: patch: reorder headers in query string

by kelson＠pobox.com

place wrote: > - There's some kind of blog thing that knows which browsers send an Accept > header. If I pretend to use one of them, I get a meaningless error page. > This is good because it saves me from wasting time looking at blogs. Probably this: http://www.bad-behavior.ioerror.us/ It's a filter written in PHP to block spambots and harvesters that pretend to be well-known user-agents. If a user-agent always sends certain headers, then a request that claims to be that UA but lacks those headers can be treated with suspicion. If a UA claims to be Opera, Gecko, Safari, IE, etc., it will check for an Accept header. One check that I find interesting is looking for invalid Windows versions. IE will always list the internal Windows version, like "Windows NT 5.1", but people programming bots will often forget this and tell it to use "Windows XP" instead. It also checks for bots that claim to be well-known search spiders. Some bots will pretend to be Googlebot, for instance, but won't come from a Google-owned IP address. Occasionally it does run into problems with personal firewalls that strip out headers. -- Kelson Vibber www.hyperborea.org

March 13, 2008

[patch] reduce malloc/free use a bit

by Johannes.Hofmann＠gmx.de

Hi, the patch below reduces the use of malloc/free a bit. For loading http://www.w3.org/TR/xslt for example it reduces the number of calls to dMalloc() from 76735 to 50478 (according to gprof). I have removed the SPCBuf member of html, as it seems not to be used. Please correct me if I'm wrong or it is intended to be used for in the future. Cheers, Johannes diff --git a/src/html.cc b/src/html.cc --- a/src/html.cc +++ b/src/html.cc @@ -295,8 +295,6 @@ public: //BUG: for now everything is pu Dstr *Stash; bool_t StashSpace; - - char *SPCBuf; /* Buffer for white space */ int pre_column; /* current column, used in PRE tags with tabs */ bool_t PreFirstChar; /* used to skip the first CR or CRLF in PRE tags */ @@ -823,8 +821,6 @@ DilloHtml::DilloHtml(BrowserWindow *p_bw Stash = dStr_new(""); StashSpace = FALSE; - SPCBuf = NULL; - pre_column = 0; PreFirstChar = FALSE; PrevWasCR = FALSE; @@ -1011,7 +1007,6 @@ void DilloHtml::closeParser(int ClientKe delete (stack); dStr_free(Stash, TRUE); - dFree(SPCBuf); dStr_free(attr_data, TRUE); /* Fit the UTF-8 buffer */ @@ -1430,9 +1425,7 @@ static void Html_process_space(DilloHtml html->SPCPending = FALSE; } else if (parse_mode == DILLO_HTML_PARSE_MODE_VERBATIM) { - char *Pword = dStrndup(space, spacesize); - dStr_append(html->Stash, Pword); - dFree(Pword); + dStr_append_l(html->Stash, space, spacesize); html->SPCPending = FALSE; } else if (parse_mode == DILLO_HTML_PARSE_MODE_PRE) { @@ -1475,8 +1468,6 @@ static void Html_process_space(DilloHtml /* SGML_SPCDEL ignores white space inmediately after an open tag */ html->SPCPending = FALSE; } else { - dFree(html->SPCBuf); - html->SPCBuf = dStrndup(space, spacesize); html->SPCPending = TRUE; } @@ -1510,9 +1501,7 @@ static void Html_process_word(DilloHtml } else if (parse_mode == DILLO_HTML_PARSE_MODE_VERBATIM) { /* word goes in untouched, it is not processed here. */ - Pword = dStrndup(word, size); - dStr_append(html->Stash, Pword); - dFree(Pword); + dStr_append_l(html->Stash, word, size); } if (parse_mode == DILLO_HTML_PARSE_MODE_STASH ||

March 12, 2008