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

Re: [Dillo-dev]HTTPS certificate support
by Garrett Kajmowicz July 23, 2004

July 23, 2004

> Producing code quick is not the goal. The point is to produce > well designed code that works OK, and that's easy to > read/review/follow and thus to maintain. I'm spending a lot of time on this because I've been working on a project for several months to revamp some PCs with 32MB of RAM to be sent to the homes of deaf people. I'm running a uClibc based distribution, but I need a good web browser which works. Thus I want to get this done as soon as possible. > The problem I found (and probably your classmates) is that > reviewing rushed-code takes more time than necessary, and once > understood, it changes. In my case is a bit worst because I took > the extra time to polish it, only to find it back with my work > wasted. I crank out a lot of code because I think quickly and clearly, and have no life. If I could comit often enough, I could gurantee you about 4 hours/day solid development for the next month and a half. More if I dropped another pet programming project and some metal work I am doing. I am usually the person doing the code reviews. I'm also the person who tends to put the most documentation into my code to make the most redably readable. > Let me suggest you a second stage after your code is working. > Stop, and take the same amount of time polishing it. Think of the > design, long functions, multiple exit points, global variables, > data structures, future additions, variable names, memory > management, comments, etc. > > Once you finish this second stage, testing for robustness will > be much easier (third stage). Once you've done it, your > classmates will love your code. Most of my classmates can't program *snort*. Then again, neither can the comp sci professors..... > Just an example, multiple exit points make code more complex to > grasp because you have to understand the flow of execution of > each one of the exits, before having confidence of not breaking > it with some changes. I would disagree with that point. With single exit point functions, you have to carry a variable (extra stack allocation) through the application and all code. Thus you can either have large numbers of nested statements (which is very effective and reasonably clean, but excedes line length) or you have your finalized variable being carried through the rest of the application with nothing else to do. With the multi-exit point strategy, you can exit the application as soon as you are done done whatever it is that you need to do. This way you aren't hanging around in the code any more. I have found that tends to make for better code than single-exit writing. > > Another big problem comes with finalization code (freeing > memory, leaving variables in a stable state, return codes, side > effects...). > > Take for instance yes_ssl_support(). Look at the many exit > points and its finalization code, and compare with a single exit > code version. > > It took a lot of time. > > Please follow my advice. Since this is the preffered coding standard (I suggest adding it to the coding standards on the web) I will follow it as you wish. I will follow any coding standards to the letter, and will take suggestions as I see fit. I will modify everything that I have writen to conform to your preferences, and resubmit. I'm tempted to blow away all of my work and start over sust so I can have a sync'd tree to make sane diffs against. *sigh* - Garrett

1 0

[Dillo-dev]HTTPS certificate support
by Garrett Kajmowicz July 22, 2004

July 22, 2004

OK - this patch backs out a few trivial changes which were made about 2 patches ago due to code redundancy and are no longer needed. This patch detects self-signed certificates and gives the user the option to permanently trust them, autosaving to the .dillo/certs directory. Please give this a whirl, and then commit it. Let me know when done so I can while my current devel tree clean and get a new copy - this way I don't have to manually correct all of the spelling errors with each patch :-) - Garrett

2 3

Re: [Dillo-dev]More https goodness
by Jorge Arellano Cid July 21, 2004

July 21, 2004

Hi Garret, On Fri, Jul 16, 2004 at 08:05:43PM -0400, Garrett Kajmowicz wrote: > I am going to start by appologizing: this diff contains two separate items. I > needed to do one to get the other to work, and I didn't want to risk having > one patch getting applied before the other. > > Anyways, two things done: > 1) Added a function to dpiutils which does the complete read in from stdin > for the dpi response tag and returns the option number selected. Please feel > free to add comments about error return values and so forth. > > 2) Added *preliminary* error checking in the https dpi which notifies the > user in the event that no certificate is presented or that the certificate is > not verified. I will do a more thorough breakdown and other options once I > know that this meets spec. Let me know if you prefer different wording on > the messages as well. > > In short, please review and commit. OK, I reviewed it an made some changes (now on CVS). I pondered a long time whether to make a generic function for parsing dpip dialog answers. Something like: a_Dpiutil_dialog_parse_answer(...) To me it seems that according to the simplicity principle of API design, sticking with Get_attr_value() instead of one custom parsing function per each dpip command is better... The same logic applies to the a_Dpip_build_command() I was thinking of. The interface for sending data may survive though. Anyway, the most important point of this patch is that after applying the patch, it seems not to trust even paypal! For instance: https://www.paypal.com/en_US/i/icon/secure_lock_2.gif gives me the warning dialog. Is this OK? Cheers Jorge.- PS: For those using CVS, you can avoid the dialogs by setting 'retval = 0' in https.c.

2 3

[Dillo-dev]any documents about html parser?
by Calvin Yu July 21, 2004

July 21, 2004

Hello everyone: Are there any documents about html parser in Dillo? It seems HtmlParser.txt is too brief. And it is not easy to analyse the code about html parser. Thanks a lot!

2 1

[Dillo-dev]form fields too narrow
by Thorben Thuermer July 21, 2004

July 21, 2004

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

2 1

Re: [Dillo-dev]dpip dialog for https (and dpis in general)
by Jorge Arellano Cid July 21, 2004

July 21, 2004

Garret, Brian, CC: anyone interested ;) On Fri, 16 Jul 2004, Brian Hechinger wrote: > On Thu, Jul 15, 2004 at 11:31:12PM -0400, Jorge Arellano Cid wrote: >> >> I'll test and upload tomorrow. > > let us know, i'd love to test it. i just setup a new machine, and the latest > dillo in NetBSD's packages collection is 0.8.1, so i'm ready to upgrade > anyway. ;) The changes are now in the CVS. Example code can be find in the hello dpi (and also in nav.c). For instance, after upgrading the dpi binaries, launch Dillo and load this url "dpi:/hello/world". It will pop up a dialog, make a choice and look at the answer. repeat the test by going Back and Forward (the hello dpi is set to always reload). The relevant code is well commented. Look inside the hello dpi and you can also review the new dpiapi.[ch] files. Nav.c has an example of use for a_Interface_question_dialog() too. This should be enough for asking the user about certificates that can't be authenticated. Note that the code is not final, i.e. it needs some polishing and extensions. The good news is that in clearly illustrates the process and now is much easier to do it so. even the data structures and interface was thought to be extensible. Cheers Jorge.- Brian: unless you're interested in dpi development, or want to alpha test the https dpi, I'd recommend 0.8.2 as an upgrade.

3 6

[Dillo-dev]https patch
by Garrett Kajmowicz July 19, 2004

July 19, 2004

This patch allows the https dpi to release the memory used by the X509 certificate. This is a trivial patch. The call used to check the certificate increases a reference count, but it is never decreased, causing the memory not to be freed at the optimum time. This is not actually needed on a Linux system because of the MMU, but in the event this is converted to a server or run on a MMU-less processor, this could cause problems - I'm not familiar enough with the internals of OpenSSL to be certain. Anyways, please apply the following patch to CVS. btw, my configuration script diff seems not to have been applied yet. Are there any standards that I should be complying with that I am not? Thanks. More stuff to follow tonight. - Garrett

3 3

Re: [Dillo-dev]Cookie problem
by Brian Hechinger July 18, 2004

July 18, 2004

i told him about cookiesrc, he's going to try that. but that brings me to a cookie issue of my own. i have: ebay.com ACCEPT in my cookiesrc, but ebay keeps telling me that my browser is rejecting cookies. am i doing something silly? -brian On Sat, Jul 17, 2004 at 12:38:31PM +0200, Claus Conrad wrote: > Dear dillo community, > > I have subscribed to this list because I'm developing a PHP-based website > which I want to be compatible with dillo. The site is located at > http://www.kabbeleje.dk/vask/ . It uses PHP's session management, sending a > cookie named PHPSESSID to the browser on login. This works great in most > other browsers I tried, but somehow not in dillo. > > The PHP code I'm using looks something like > if (login_successful) { > session_start(); > // ... > header("Location: http://" . $_SERVER['HTTP_HOST'] . > dirname($_SERVER['PHP_SELF']) . "/index.php?PHPSESSID" . > strip_tags(session_id())); > } > > I added the get parameter to the redirect URL after trying without; both > ways seem to work in e. g. Mozilla, but it doesn't change anything in dillo. > The redirect works, but the user isn't logged in. I guess it's just a minor > erroneous piece in the code, but don't know where to look. Any help would be > very much appreciated. A test login is available on request, if necessary. > Thanks a lot in advance. > > Regards, > Claus > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev -- "Suits, man. They are as incapable of logical thought as they are of honesty." -- Dave McGuire --

2 2

[Dillo-dev]Configure script patch
by Garrett Kajmowicz July 16, 2004

July 16, 2004

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

2 2

[Dillo-dev]dpip dialog for https (and dpis in general)
by Jorge Arellano Cid July 16, 2004

July 16, 2004

Hi there, In the afternoon I had a prototype working, wich BTW was very pleasing to see working, after living a long time as an abstract design. It needed some touches, and while working on them, some hidden bugs outside its scope showed in nav.c's repost dialog. Short story, I decided to integrate some code in interface.c with the new dialog renderer, use a more flexible design and fix the bugs. I'll test and upload tomorrow. Cheers Jorge.-

1 0