November 2003 - Dillo-dev - lists.mailman3.com

Simulating a slow connection

by Sebastian Geerken

Hi! Sorry for being silent the last week. At <http://www.dillo.org/download/dillo-slow-0.0.1.tar.gz>, you'll find a dpi, which simulates a slow connection, and is useful for testing incremental rendering. Read the README file within the tarball for more informations. (I'm not yet very familiar with dpip, I just modified the "hello world" example for my needs, and especially, currently only one instance of this dpi can run at a time.) Sebastian

Nov. 3, 2003

Re: https dpi

by Jorge Arellano Cid

On Sat, 25 Oct 2003, Madis Janson wrote: > I read the https.c included in dillo/dpi and seams, that it just > gets url and and dumps html. Yes, it's basically a dpi filter plugin. > What about content-type, cookies and POST > requests? Since https is http over ssl, it seems natural to use dillo's > http protocol implementation for these things (like i did with my https > proxy for dillo), but is it possible with dpi? > > Also, there seems to be one process for one connection, which makes hard > to implement SSL session cache. Unfortunatelly I don't have definitive answers for these questions. There's more than one way to do it and the choice somewhat depends on what the underlying purpose of the bigger picture is. For instance: distributed design vs monolithic, quick implementation vs a more flexible one, low library dependencies vs linking dillo to a bigger set. Personally, I think that patching dillo with an integrated quick implementation of https (like Indan's) while we develop a more flexible dpi that provides at least the same, can be a good approach. I'll try to briefly comment your concerns: > Also, there seems to be one process for one connection, which makes hard > to implement SSL session cache. Yes, that happens with dpi filters. The idea in this case is to have an http dpi that's able to handle several connections at the same time (like the downloads dpi). That is: a dpi server instead of a dpi filter. With that scheme session cache is easy to implement. (and BTW much easier for the developer because he can arrange things much more freely than when patching inside dillo). > content-type (as above). The https dpi would need to listen the HTTP stream and so has access to the content-type sent by the remote https server. > Cookies Cookies will end being a dpi! Currently dillo enables cookies for the first instance only (this is old problem of sharing a single resource among several clients). Fortunately dpi solves this, as with the current bookmarks dpi server that can be shared by multiple running instances of dillo. When this port is done, the one-instance-only restriction for cookies will be gone. > POST POST data can be passed to the https dpi using dpip. This information is inside the DilloUrl. > Since https is http over ssl, it seems natural to use dillo's > http protocol implementation for these things (like i did with my https > proxy for dillo), but is it possible with dpi? Yes I agree with that reusing dillo's http may come handy. Now, dillo does http 1.0 only so having it done inside a dpi can also bring http 1.1 (as with wget and current https.c). The other interesting point is that the SSL/TLS library spec states that appart from making a socket secure, the details of handling the possible errors should be solved by the client application depending on the protocol and what it is being used for. So having a generic SSL/TLS gateway may look interesting but it can get tricky to implement. For intance: handshake_failure(40), bad_certificate(42), unsupported_certificate(43), certificate_revoked(44), certificate_expired(45), certificate_unknown(46), illegal_parameter(47), unknown_ca(48), are to be handled in different ways regarding what the protected protocol using SSL/TLS is, the transport circumstances and the user's choice. (ah, and all the alerts can have a "level" of fatal or not). With a gateway, having only the option of closing the connection is not enough. Question dialogs can be implemented in the gateway process itself though (a GUI inside the dpi), and you also have to take care of differentiating the protocols. With dpi, the questions and actions can be communicated to dillo with dpip or be made part of the dpi server. It provides more flexibility. Making SSL a part of IO, comes with the burden of having to develop all of this error handling knowledge inside the IO layer (making dillo grow in size and complexity). Including questions, actions a protocol differentiation. HTH Jorge.-

Nov. 3, 2003

Re: [Dillo-dev] libpng detection again...

by Andreas Schweitzer

Hi, > <current line> > CPPFLAGS="$CPPFLAGS `$PNG_CONFIG --I_opts`" > </current line> <snip> > <candidate line> > CPPFLAGS="$CPPFLAGS `$PNG_CONFIG --cppflags`" > </candidate line> Total approval from my side ! Yes, the two options give slightly different results, but the differences don't matter. The problem is, the png developers first introduced the --cppflags options in release 1.2.4 and in 1.2.5 they furthermore introduced --I_opts (and more fine grained flags). And dillo, of course :-), expects the latest release of libpng. So all distributions stuck at release 1.2.4 have this problem we are seeing (e.g. Suse 8.1). But moving to the more comaptible --cppflags version will fix this particular problem. Cheers Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Nov. 3, 2003

libpng detection again...

by Jorge Arellano Cid

Hi, We've been through this several times, and today I received one more suggestion that may work: The whole point is replacing the current line in configure.in with something better ;). <current line> CPPFLAGS="$CPPFLAGS `$PNG_CONFIG --I_opts`" </current line> Kelson and Raphael had to patch for SUSE 8.1: http://article.gmane.org/gmane.comp.web.dillo.devel/1011/match=libpng http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-April/000532.html Basically: <patched line> CPPFLAGS="$CPPFLAGS -I/usr/local/include/libpng12" </patched line> and here's the new candidate: <candidate line> CPPFLAGS="$CPPFLAGS `$PNG_CONFIG --cppflags`" </candidate line> At least it looks clean! The funny thing is that on my box, the "candidate" and "current" give different results, but it works with either one! :-) Worth a try? Surely. Please give a test to the candidate and tell us how it works for you. Cheers Jorge.-

Nov. 3, 2003

Re: [Dillo-dev] [PATCH] memory leak in dw_ext_iterator

by Jorge Arellano Cid

On Mon, 3 Nov 2003, Frank de Lange wrote: > Hi'all, > > There's a memory leak in dw_ext_iterator, which causes every call to > dw_ext_iterator_new() to leak one DwIterator. The solution is simple, as > can be seen in the attached patch. > > Jorge, can you apply this? Done! > It saves quite a bit of memory, and will do > so even more once my next kbnav patch is out (now testing). Is this next kbnav patch CVS-ready, or a testing version? > The patch > currently contains this fix for dw_ext_iterator (plus a whole lot of > other changes to it). With regard to the other changes (to dw_ext_iterator), you can consult them with Sebastian (he developed the iterators). Thxs! Jorge.-

Nov. 3, 2003

IPv6

by Jorge Arellano Cid

Hi there! Please someone give a test to the CVS's IPv6 code. It has some new memory handling calls and it'd be good to be sure it works as expected. Just navigating will do, but the key point of the test is when dillo has to retry with different IPs for a single connection (that is: when the GioChannel is reused). Cheers Jorge.-

Nov. 3, 2003

[PATCH] memory leak in dw_ext_iterator

by Frank de Lange

Hi'all, There's a memory leak in dw_ext_iterator, which causes every call to dw_ext_iterator_new() to leak one DwIterator. The solution is simple, as can be seen in the attached patch. Jorge, can you apply this? It saves quite a bit of memory, and will do so even more once my next kbnav patch is out (now testing). The patch currently contains this fix for dw_ext_iterator (plus a whole lot of other changes to it). As this would make the patch fail to apply cleanly, I'd like to see this fixed in CVS. Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ] diff -pruN dillo/src/dw_ext_iterator.c dillo_patched/src/dw_ext_iterator.c --- dillo/src/dw_ext_iterator.c 2003-07-12 19:35:50.000000000 +0200 +++ dillo_patched/src/dw_ext_iterator.c 2003-11-03 13:58:35.020401864 +0100 @@ -366,7 +366,7 @@ gint a_Dw_ext_iterator_compare (DwExtIte void a_Dw_ext_iterator_free (DwExtIterator *eit) { int i; - for (i = 0; i < eit->stack_top; i++) + for (i = 0; i <= eit->stack_top; i++) a_Dw_iterator_free (eit->stack[i]); g_free (eit->stack); g_free (eit);

Nov. 3, 2003

Re: referer

by Jan.Stary＠ff.cuni.cz

:Dillo does NOT send referer header, if you mean this. Well ... why not? jan

Nov. 3, 2003

Re: [Dillo-dev] (no subject)

by Madis Janson

On Mon, 3 Nov 2003 Jan.Stary(a)ff.cuni.cz wrote: > Hello, > > using the usual "http://validator.w3.org/check/referer" doesn't > seem to work in dillo. On the validator page, you get a "302 > Moved", which dillo _does_ follow, but the resulting > "http://validator.w3.org/check/referer?uri=" is of no use. > > I tried viewing http://www.stare.cz/referer.html and clicking 'validate' > in lynx, mozilla and dillo. In dillo it does not work. > > Is dillo really _sending_ the referer? > Dillo does NOT send referer header, if you mean this.

Nov. 3, 2003

(no subject)

by Jan.Stary＠ff.cuni.cz

Hello, using the usual "http://validator.w3.org/check/referer" doesn't seem to work in dillo. On the validator page, you get a "302 Moved", which dillo _does_ follow, but the resulting "http://validator.w3.org/check/referer?uri=" is of no use. I tried viewing http://www.stare.cz/referer.html and clicking 'validate' in lynx, mozilla and dillo. In dillo it does not work. Is dillo really _sending_ the referer? Thanks Jan

Nov. 3, 2003