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

[Dillo-dev]Configure script patch

by Garrett Kajmowicz

This patch updates the configuration system to chack for OpenSSL libraries, and compile appropriately. I have tested to make sure that the system work with both ssl enabled and disabled, though I do not know how well it will react to not have OpenSSL present at all. Along wwith those changes go changes to the https.c file to take advantage of this newly available information. In the event that it is compiled without ssl support, an error page will come back indicating that the dpi was compiled without ssl support, and link to the openssl website. btw, is there any easy command which will delete all of the non CVS files? make distclean seems to keep the configure script around, along with other cache information. - Garrett Kajmowicz

July 14, 2004

Re: [Dillo-dev]Re: HTTPS

by Garrett Kajmowicz

> Typical console error mesage (from yahoo mail secure logon page) > > lookes like: > |----------------- > > Nav_open_url: > Url=>https://login.yahoo.com/config/login?.branch=&.src=ym&.v=0&.u=bh9jje50 >fau8u&.last=&promo=&.intl=us&.bypass=&.partner=&pkg=&stepid=&.done=< url_str > = > https://login.yahoo.com/config/login?.branch=&.src=ym&.v=0&.u=bh9jje50fau8u >&.last=&promo=&.intl=us&.bypass=&.partner=&pkg=&stepid=&.done= main.c:153: > get_command: dpid tag is NULL > > : main.c:326: main: get_command failed > : {In https.filter.dpi} > > SSL_connect failed > Dpi: [Dpi_process_io] IOClose > > |----------------- > > and dillo provides no other feedback. Since I usually involk > dillo from my window manager, the console output is not normally > availible to me. I will take a look at it as soon as a I get a chance. > > Perhaps returning a SSL connection failed page would be nice. I'll see what I can do. I'm worried about code bloat, esp since Dillo prides itself on being very small. > > Dumb question: Is http 1.1 authentication amenable to a similar > treatment? That is one of the features I really miss. http 1.1 *anything* would require Dillo to support HTTP 1.1 When workingo n the HTTPS plugin, all of the requests that I pass through are HTTP 1.0 messages, meaning that we are indicating, at least to the other server, that we don't support any HTTP 1.1 features. Actually, all the HTTPS filter DPI does is open up an SSL connection to the remote computer and then pass all the HTTP connections through. THe only thing that makes it complicated at all is dealing with certificate isssues if they are invalid. - Garrett Kajmowicz

July 14, 2004

Re: [Dillo-dev]Re: HTTPS

by David McKee

On Tue, 13 Jul 2004, Jorge Arellano Cid wrote: > I just finished uploading my patches to the dpis (those that > were independent from your code but that required a merge) and > the tarball tree you sent me. Compiled and ran find on my Debian 3.0 system. Compiled on my tweaked RedHat 6.2 system, but it won't actually open some of the https URLs I tried. Typical console error mesage (from yahoo mail secure logon page) lookes like: | |----------------- Nav_open_url: Url=>https://login.yahoo.com/config/login?.branch=&.src=ym&.v=0&.u=bh9jje50fau8u…< url_str = https://login.yahoo.com/config/login?.branch=&.src=ym&.v=0&.u=bh9jje50fau8u… main.c:153: get_command: dpid tag is NULL : main.c:326: main: get_command failed : {In https.filter.dpi} SSL_connect failed Dpi: [Dpi_process_io] IOClose |----------------- | and dillo provides no other feedback. Since I usually involk dillo from my window manager, the console output is not normally availible to me. Perhaps returning a SSL connection failed page would be nice. The funny part is I could open a yahoo mail account over a secure connection from the Debian machine... Nor do I understand why it opens some, but not all secure URLs. Anyway, it looks like a good start and I'm very pleased to see it. Dumb question: Is http 1.1 authentication amenable to a similar treatment? That is one of the features I really miss. Thanks all, -- -- David McKee -- dmckee(a)jlab.org -- (757) 269-7492 (Office)

July 14, 2004

[Dillo-dev]form fields too narrow

by Thorben Thuermer

Hello, it seems that dillo renders all text input fields in forms one character too narrow, for example on: http://www.efa.de/gvh/XSLT_TRIP_REQUEST2?language=en we have: <INPUT NAME="itdTimeHour" VALUE="17" SIZE="2" MAXLENGTH="2" ...> (field for the hour of the time) which clearly requests to be two charcters, but ends up having space for only one, making it hard to use (horizontal scrolling). in the source (html.c) i found: if ((attrbuf = Html_get_attr(html, tag, tagsize, "size"))) gtk_widget_set_usize(widget, strtol(attrbuf, NULL, 10) * gdk_char_width(widget->style->font, '0'), 0); which makes the fields too narrow... changing it to (1+strtol(attrbuf, NULL, 10)) fixes the problem. i can only assume that 'gtk_widget_set_usize' sets the *outside* dimensions of the widget? (or that something else is off there...) - Thorben

July 14, 2004

Puppy Linux 0.9.1 has Dillo, works fine

by Barry Kauler

Hi guys, Just a comment because I started a thread a little while ago, that never got resolved. The 0.8.x series of Puppy Linux had all the apps compiled against uClibc, which saved about 1M but caused various compatibility problems. One of those was the Dillo plugins not working right. That problem never got resolved, however it is now academic as far as Puppy is concerned, as I recompiled everything against glibc, for Puppy 0.9.0 (using Mandrake 9.2 as the host). Having finished with that, I wish to make one further interesting comment. Puppy is a tiny distro, the live-CD is only 49M, designed to fit on a business-card-size CD, and easily install to usb pen drive or Zip drive. The widget libraries used are only GTK 1.2, Xaw95 and Tk/tix/bwidget. I also installed the gdkxft package, which is a fairly small library that bolts font antialising onto GTK 1.2 apps. I wish to report that it works brilliantly with Dillo. The latest Puppy. v0.9.1, has Dillo with font antialiasing and it sure looks good. Note that one interesting thing about gdkxft, for anyone else interested in trying it, is that it can be applied on a per-application basis, without recompiling the app. You just install libgdkxft.so, then do this when launching Dillo: LD_PRELOAD=/usr/lib/libgdkxft.so dillo There is a config file, /etc/gdkxftrc I think it's called, and all you do is put a single "*" in it, which means apply antialiasing to all fonts. Puppy home page: http://www.goosee.com/puppy News page: http://www.goosee.com/puppy/news.htm Regards, Barry Kauler

July 14, 2004

Re: [Dillo-dev] Puppy Linux 0.9.1 has Dillo, works fine

by Garrett Kajmowicz

> Hi guys, > Just a comment because I started a thread a little while ago, that never > got resolved. > > The 0.8.x series of Puppy Linux had all the apps compiled against uClibc, > which saved about 1M but caused various compatibility problems. > One of those was the Dillo plugins not working right. > > That problem never got resolved, however it is now academic as far as Puppy > is concerned, as I recompiled everything against glibc, for Puppy 0.9.0 > (using Mandrake 9.2 as the host). That is too bad. My development system for Dillo is a chroot environment running off of uClibc. Regular glib and gtk were installed. If you are looking for a good distro to base your Linux distro off of, check out uwoody at www.uclibc.org - Garrett Kajmowicz

July 14, 2004

[Dillo-dev]Re: HTTPS

by Jorge Arellano Cid

Hi Garret, I just finished uploading my patches to the dpis (those that were independent from your code but that required a merge) and the tarball tree you sent me. It comes with some minor modifications ... > Let me know what you think of the coding style, etc. Very clean and compliant with our Naming&Coding in general. I did minor changes, like keeping it inside 80 columns and switching "if(" to "if (" (not a requirement but just to be consistent with the rest of Dillo). Only in one function I needed to reindent to 3 spaces... Unto less trivial stuff, Makefile.am was modified so dpiutil.h gets in the tarball produced with `make dist`. It would be great if you can add some SSL library detection routine to configure.in so https.c uses the no_ssl_support() function when the libarry is not present (or detected). > Also, if you could give me some direction on how to implement the prompt for > unverified certificates (and the code/location to save them to), it would be > greatly appreciated. I'm working on this. Maybe tomorrow... For those that feel curious, you can get the latest CVS and test the new dpis. Just remember to install them after typing make! :-) More seriously, kill dpid and any running dpi before: 'make install' (or 'make install-strip'). Best Jorge.- PS: great start for 0.8.3-pre!

July 13, 2004

Re: Fwd: Re: [Dillo-dev]Plugin infrastructure

by Jorge Arellano Cid

On Mon, 12 Jul 2004, Garrett Kajmowicz wrote: >> In the discussions before introduction of dpi was the point UI could >> entierely be done using standart html, rendered by dillo itself. >> >> Maybe we could use this here. >> >> I would see two (new) dpi commands: >> -Pop a new dillo window (maybe with some args: modal, no toolbar, no >> addressbar..., set its size, url) >> -Make a window reload >> >> So dpi could make a window pop for asking anything about certificates, >> with a standart html form in it. It would allow to change window title >> (through <title>) and make the gui customisable for future needs, and >> even be portable for gtk->other toolkit change. >> >> I thought of the 'reload window' feature not directly for https, but for >> download dpi. This would allow us to update the status of current >> downloads; shown in a dedicated window, somewhat ala Firefox, but again, >> entierely in html. Yes Nicolas, the html interface is an important part of the dpip feature set. Now, each dpi is different and that's why flexibility is important. I mean, for bookmarks and preferences (and probably for general purpose applications like the dillo-based control center of DSL linux), HTML is perfect. For the downloads, a native GUI inside the dpi, is an easier approach, and in the https case, dialog windows through Dillo by means of a dpip request seem to be the most adequate. > > That is very interesting, but causes two problems. First of all, from what I > have seen , it looks like it would be difficult to implement modal dialog > boxes. This is important for security warnings so that they are not hidden > or confused with other Dillo warnings. > > Secondly, this approach causes some problems. I am approaching this from the > perspective of the https filter dpi, but I assume that the same problem would > apply to any other related dpi. > > Firstly, a filter dpi runs in its own process for each call, not as a server. > Thus every time a call is made to the https filter dpi, it runs in its > entirety. This makes it difficult to handle a response from the user because > the dpi is then required to write a web server capable of at the very least > parsing http GET requests, which means opening up a socket and so forth. > Needless to say, handling that is somewhat of a challenge from a filter dpi > perspective. > > Secondly, for the https application, cookie/post/get datais likely to be > sent, which means that any rerequest would have to be able to pass that data > on exactly. > > Third, the https verification needs to be done after the ssl session is > estabilshed, but before the http request is made (for security reasons). > Thus any complicated scheme could result in multiple connections being made. > > Fourthly, I don't like it. That's the most important one of all :-) It's important to notice that coding the https dpi as a server (instead of a filter) has some advantages. BTW, this is what we have in mind with Madis. A server https dpi can more easily manage session caching and certificate management (remembering, saving, loading, ...). A single instance that forks or launches threads to do the work while keeping a common central management. BTW, we agree that implementing and testing with a filter dpi before turning it into a server dpi is a good approach. > > The html prompt window isn't a bad idea, but causes a lot of coding headaches > on the dpi other end. But that's just my thought. If you think that an > html prompt window would work, I'd appreciate a modified "hello" filter dpi > as an example from which I could implement the required code. In this case we'll try the dialog window with dpip... I foresee this tasks (by my side): 1.- Merge the https into the CVS so you can sync from there. 2.- implement a dpip command to provide for a simple dialog. (so handle_certificate_problem() can be filled in). 3.- Polish the common API for developing dpis and adjust the dpi set to the new functions. 4.- Implement a dpip_build_command() function into the lib and make the dpi set use it. 5.- Merge my new patches for bookmarks, downloads, and interface inside dillo. 6.- Review the file dpi. I hope to have this done and uploaded by Friday (1 to 5). Now, only 1.- and 2.- constitute a bottle neck for https, so I'll try to push them first (hopefully by Wednesday). The idea is to remove the bottleneck so you can keep on working and testing the https dpi. Cheers Jorge.-

July 13, 2004

[Dillo-dev]0.8.2 - No PNG support, but config cound PNG available (attachment)

by Geek

Hi, I just compiled and installed 0.8.2 on my Debian stable and gave it a shakedown. It doesn't display PNG images. 0.8.1 and earlier, no problems. I have attached the config.log file Thanks for any assistance. -- Gregg t3h g33k http://geek.scorpiorising.ca

July 13, 2004

RE: [Dillo-dev]Plugin infrastructure

by Eric Gaudet

Dillo's html rendering capabilities are what we should use for advanced forms. We don't want to duplicate the form widgets into a native-gtk version like mozilla does with xul. The pageflow, the forms, images etc ought to be in html, even if it's a dpi serving them. Having a login/password modal box seems to be what people are used to, so I can see why we'd like to have that. I can imagine dpis other than https needing a login/password box, but I'm not sure I can imagine that for non-login purposes. In any case, anything more complicated than one string, one or two text boxes with lables (possibly hidden for passwords) and 1 or 2 buttons certainly belongs to a dedicated html page the dpi would build. I could live with an intermediate html login page for https or any other dpi myself. Best, EG > -----Original Message----- > From: dillo-dev-admin(a)auriga.wearlab.de > [mailto:dillo-dev-admin@auriga.wearlab.de] On Behalf Of > Garrett Kajmowicz > Sent: Monday, July 12, 2004 3:26 PM > To: dillo-dev(a)auriga.wearlab.de > Subject: Re: [Dillo-dev]Plugin infrastructure > > > I just came up with two other dialog box types we might need: > > A window with alterable caption/message text and either one > or two text boxes > with associated labels. One or both of the boxes should be > able to be set in > "password" mode. > > I'm not sure if that counts as one or two, so I'm inflating > my estimates to > look more impressive :-) > > - Garrett Kajmowicz > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-> bin/mailman/listinfo/dillo-dev > >

July 12, 2004