- Dillo-dev - lists.mailman3.com

Segfault on sites requiring authentication

by tim.nieradzik＠gmx.de

Whenever I visit http://puppyisos.org/isos (puppy / linux), Dillo segfaults. The reason is that in some cases the variable Client_bw is NULL. However, some functions depend on it and access its member variables. Client_bw is initialized in Cache_process_queue() (src/cache.c). When authentication is required, this variable is passed over to Cache_auth_entry() which sets a timeout. Its callback (Cache_auth_callback()) opens up a dialog asking for the credentials and then calls a_Nav_reload() with the Client_bw as its first parameter. Finally in a_Nav_cancel_expect() Client_bw's member variable nav_expecting is used and as bw is NULL, Dillo segfaults. I came up with a small patch that removes Cache_auth_callback() and Cache_auth_entry() as I have not seen any advantages in delaying the authentication popup. The next thing I did was to show the dialog on condition that Client_bw is not NULL and that we have finished the transfer (At least I hope CA_Close is the proper flag for doing so). There were various unnecessary checks in src/nav.c. They compared bw with NULL. In my opinion the affected functions (a_Nav_expect_done, a_Nav_push and a_Nav_repush) should never be called if you cannot be sure that bw is not NUL. What is your view on this subject? Unfortunately, my approach does not solve the original problem that caused Client_bw being NULL. Furthermore, the patch introduces a new bug: The dialog pops up when reloading the site but after having entered the correct credentials or having pressed the ``Cancel'' button, it appears again. Any ideas? While digging deeper into the code, I noticed that we make heavy use of timers for popups and reloading pages? Is there any special reason for it? --Tim

April 1, 2009

tools button name (a very trivial matter)

by corvid＠lavabit.com

Jorge wrote: > On Sat, Mar 28, 2009 at 12:02:59AM +0000, corvid wrote: > > I was going to update the dillorc comment for load_images > > (still mentions the old dedicated button), and... > > to developers, it's in the Tools button's menu now, > > but to users, it's the Settings button because that's > > what the tooltip says. > > ... and the button text-label is "Tools". > > > We should standardize on one name or the other. > > The tooltips explain briefly what each button does. In this > case it could also be: "Browser settings", "Customize browser > behaviour", "Browser tools", "Browser preferences" or similar. > I'd keep "Tools" as the name of the button and try to find a good > tooltip text. All right, then I can either call it "Browser tools" in the tooltip or be careful always to call it the tools/settings button in documentation.

March 29, 2009

tools button name (a very trivial matter)

by jcid＠dillo.org

On Sat, Mar 28, 2009 at 12:02:59AM +0000, corvid wrote: > I was going to update the dillorc comment for load_images > (still mentions the old dedicated button), and... > to developers, it's in the Tools button's menu now, > but to users, it's the Settings button because that's > what the tooltip says. ... and the button text-label is "Tools". > We should standardize on one name or the other. The tooltips explain briefly what each button does. In this case it could also be: "Browser settings", "Customize browser behaviour", "Browser tools", "Browser preferences" or similar. I'd keep "Tools" as the name of the button and try to find a good tooltip text. Comments/Suggestions/Other_ideas? -- Cheers Jorge.-

March 28, 2009

tools button name (a very trivial matter)

by corvid＠lavabit.com

I was going to update the dillorc comment for load_images (still mentions the old dedicated button), and... to developers, it's in the Tools button's menu now, but to users, it's the Settings button because that's what the tooltip says. We should standardize on one name or the other.

March 28, 2009

memory use

by dillo-dev＠toykeeper.net

* Jorge Arellano Cid <jcid(a)dillo.org> wrote: > BTW, it'd be good to have some memory usage data for dillo-2.1. A while ago, I noticed that dillo was using a lot of memory on a specific page, and I didn't remember it doing that before. So I tested a few versions and found that dillo2 uses more memory initially, but less memory for large tables. Specifically: Memory use (in KiB) (on ubuntu 7.10 x86_64) dillo-0.8.6/src/dillo: 3692 file:///nothing 4900 http://dillo.org/ 45204 http://idlerpg.net/db.php dillo-2.0/src/dillo: 4700 file:///nothing 6564 http://dillo.org/ 36408 http://idlerpg.net/db.php hg/dillo/src/dillo: 4812 file:///nothing 6684 http://dillo.org/ 36756 http://idlerpg.net/db.php > Note: I remmeber having an awful memory footprint on 64bit > Ubuntu. It didn't happen with 32bit. What's the current status, > I don't know. I have both 64-bit and 32-bit ubuntu systems here, if you need measurements. For example, I tried the above on my 32-bit box: Memory use (in KiB) (on ubuntu 8.04 i686) dillo-0.8.6/src/dillo: 4916 file:///nothing 6504 http://dillo.org/ 36824 http://idlerpg.net/db.php dillo-2.0/src/dillo: 3972 file:///nothing 5732 http://dillo.org/ 25144 http://idlerpg.net/db.php hg/dillo/src/dillo: 4036 file:///nothing 5760 http://dillo.org/ 25296 http://idlerpg.net/db.php These are pretty easy to generate with a short script: #!/bin/sh BROWSERs="./dillo-0.8.6/src/dillo ./dillo-2.0/src/dillo ./hg/dillo/src/dillo" URLs="file:///nothing http://dillo.org/ http://idlerpg.net/db.php" for BROWSER in $BROWSERs ; do echo "$BROWSER:" for URL in $URLs ; do $BROWSER $URL < /dev/null > /dev/null 2>&1 & PID=$! sleep 5 MEM=`ps axu | grep " $PID " | grep -v grep | awk '{ print $6 }'` # or: expr `cat /proc/$PID/statm | cut -d ' ' -f 2` \* 4 # (to avoid bad grep matches) kill $PID echo " $MEM $URL" done done I hope this helps. -- Scott

March 27, 2009

Warnings in src/IO/dpi.c and lout/misc.hh

by jcid＠dillo.org

On Fri, Mar 27, 2009 at 01:07:14PM +0100, Hofmann Johannes wrote: > Hi, > > On Fri, Mar 27, 2009 at 12:00:46AM +0100, Michal Nowak wrote: > > Found this three warnings when compiling with gcc-4.3.2-7.i386: > > > > gcc -DHAVE_CONFIG_H -I. -I../.. -I/usr/local/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -g -O2 -DD_DNS_THREADED -D_REENTRANT -D_THREAD_SAFE -Wall -W -Waggregate-return -MT dpi.o -MD -MP -MF .deps/dpi.Tpo -c -o dpi.o dpi.c > > dpi.c: In function ?Dpi_get_dpid_uds_dir?: > > dpi.c:382: warning: ignoring return value of ?fgets?, declared with attribute warn_unused_result > > dpi.c: In function ?a_Dpi_bye_dpid?: > > dpi.c:733: warning: ignoring return value of ?write?, declared with attribute warn_unused_result > > > > g++ -DHAVE_CONFIG_H -I. -I.. -DDILLORC_SYS='"/usr/local/etc/dillorc"' -I/usr/local/include -I.. -I/usr/include/libpng12 -I/usr/include/freetype2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Wno-non-virtual-dtor -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT styleengine.o -MD -MP -MF .deps/styleengine.Tpo -c -o styleengine.o styleengine.cc > > ../lout/misc.hh: In member function ?void StyleEngine::apply(dw::core::style::StyleAttrs*, CssPropertyList*)?: > > ../lout/misc.hh:181: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false > > Can you please check whether attached patches fix the warnings? > > @all: please have a look at the dpi.c fix. It looks OK to me. I'd just: s/p1/nl/ -- Cheers Jorge.-

March 27, 2009

Warnings in src/IO/dpi.c and lout/misc.hh

by Johannes.Hofmann＠gmx.de

Hi, On Fri, Mar 27, 2009 at 12:00:46AM +0100, Michal Nowak wrote: > Found this three warnings when compiling with gcc-4.3.2-7.i386: > > gcc -DHAVE_CONFIG_H -I. -I../.. -I/usr/local/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -g -O2 -DD_DNS_THREADED -D_REENTRANT -D_THREAD_SAFE -Wall -W -Waggregate-return -MT dpi.o -MD -MP -MF .deps/dpi.Tpo -c -o dpi.o dpi.c > dpi.c: In function ?Dpi_get_dpid_uds_dir?: > dpi.c:382: warning: ignoring return value of ?fgets?, declared with attribute warn_unused_result > dpi.c: In function ?a_Dpi_bye_dpid?: > dpi.c:733: warning: ignoring return value of ?write?, declared with attribute warn_unused_result > > g++ -DHAVE_CONFIG_H -I. -I.. -DDILLORC_SYS='"/usr/local/etc/dillorc"' -I/usr/local/include -I.. -I/usr/include/libpng12 -I/usr/include/freetype2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Wno-non-virtual-dtor -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT styleengine.o -MD -MP -MF .deps/styleengine.Tpo -c -o styleengine.o styleengine.cc > ../lout/misc.hh: In member function ?void StyleEngine::apply(dw::core::style::StyleAttrs*, CssPropertyList*)?: > ../lout/misc.hh:181: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false Can you please check whether attached patches fix the warnings? @all: please have a look at the dpi.c fix. Cheers, Johannes

March 27, 2009

Warnings in src/IO/dpi.c and lout/misc.hh

by newman.x＠gmail.com

Found this three warnings when compiling with gcc-4.3.2-7.i386: gcc -DHAVE_CONFIG_H -I. -I../.. -I/usr/local/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -g -O2 -DD_DNS_THREADED -D_REENTRANT -D_THREAD_SAFE -Wall -W -Waggregate-return -MT dpi.o -MD -MP -MF .deps/dpi.Tpo -c -o dpi.o dpi.c dpi.c: In function ?Dpi_get_dpid_uds_dir?: dpi.c:382: warning: ignoring return value of ?fgets?, declared with attribute warn_unused_result dpi.c: In function ?a_Dpi_bye_dpid?: dpi.c:733: warning: ignoring return value of ?write?, declared with attribute warn_unused_result g++ -DHAVE_CONFIG_H -I. -I.. -DDILLORC_SYS='"/usr/local/etc/dillorc"' -I/usr/local/include -I.. -I/usr/include/libpng12 -I/usr/include/freetype2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Wno-non-virtual-dtor -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT styleengine.o -MD -MP -MF .deps/styleengine.Tpo -c -o styleengine.o styleengine.cc ../lout/misc.hh: In member function ?void StyleEngine::apply(dw::core::style::StyleAttrs*, CssPropertyList*)?: ../lout/misc.hh:181: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false -- Regards, Michal Nowak

March 27, 2009

google login redirect

by furaisanjin＠gmail.com

2009/3/27 Jorge Arellano Cid <jcid(a)dillo.org>: > ?Just committed a patch for this. > ?Please test. I did login and logout several times and the redirect template showed correct link. This works. Regards, furaisanijn

March 26, 2009

google login redirect

by jcid＠dillo.org

On Sat, Feb 14, 2009 at 03:44:49PM +0900, furaisanjin wrote: > Hi all. > > I have noticed that google login redirect is something like this. > > <meta http-equiv="refresh" content="0; url='http://www.google.com/ .....> > > So generated redirect template looks like > > <table width='100%'><tr><td bgcolor='#ee0000'>Warning:</td> > <td bgcolor='#8899aa' width='100%'> > This page uses the NON-STANDARD meta refresh tag.<br> The HTML 4.01 SPEC > (sec 7.4.4) recommends explicitly to avoid it.</td></tr> > <tr><td bgcolor='#a0a0a0' colspan='2'>The author wanted you to go > <a href=''http://www.google.com/ ... > > So dillo just navigates to the same page. This is the reason why we can't login. Just committed a patch for this. Please test. -- Cheers Jorge.-

March 26, 2009

Re: FLTK2 r6403

by corvid＠lavabit.com

Nicol?s wrote: > Hi! Well, I am making the possible to compile Dillo in OSX. But with > the version of FLTK v6700 i can't pass the ./configure. > I am using the v6671, but there are some differences between the v6403 > (recomended in the README file). If anyone has the v6403, send it me > please =). 6700 is FLTK 1.3. You don't want that. The README says 6403 or newer. fltk-2.0.x-6671 should be fine.

March 26, 2009

[patch] Configurable key bindings

by tim.nieradzik＠gmx.de

> After giving a couple of read-passes to the patch, and > considering that we still have some time before April (when I'll > have time to focus on the release), we can merge this long patch > in small independent chunks. Please separate them into different > patch files. > [...] I am definitely in favour of your idea but if I recall correctly many changes depend at each other. Therefore it could become difficult splitting it into separate patches. If I have a spare minute the next few days, I will try to do it anyway but from my point of view the easiest way would be to merge the patch as-is (or at least part of it). For the next patches, I know how to do it better. > [...] For instance I'd decline this: > > - Ported src/dir\.[ch] to C++ (now called src/paths\.(cc|hh)). > > (unless there's a strong reason I've not seen). It was ported since OO method calls in C++ are superior to C functions when it comes to readability (a_Dir_init() vs Paths::init(), a_Dir_get_owd() vs Paths::getOldWorkingDir()). The reason why I renamed the file was that the functions returned a path instead of only the directory. I also moved some file name constants to paths.hh because it makes sense organizing such path-related things within one file and to use an unified prefix (in this case PREFS_RC_). Anyway, I fully understand your view on this topic as my decision to use C++ is mostly preference- and aesthetics-driven. --Tim

March 25, 2009

[patch] Configurable key bindings

by tim.nieradzik＠gmx.de

> > PS: I would like to port some C files to C++ in order to achieve > > more consistency. What is your opinion on this? > > Please don't. C++ is an unfortunate compromise we had to make to > be able to use FLTK2. It has increased complexity, reduced portability > and we'd like to confine it to a minimum (in size and features). As Dillo is already using C++, porting other parts of the code will not affect the portability negatively. Moreover, it even helps us in various ways because it improves the consistency of the whole code. As long as we do not use the STL and ``advanced'' C++ techniques, there will not be any major differences between the original and the ported code. In my opinion, the biggest advantage of C++ is its OO model which could facilitate the maintainability (assumed that it is used correctly). --Tim

March 25, 2009

Ohloh does not accept http://hg.dillo.org/dillo as Enlistment for the Dillo browser.

by wine.dev＠web.de

On Fr, 2009-03-20 at 19:05 +0100, Andreas Kemnade wrote: > > ...$hd id http://hg.dillo.org/dillo > > abort: cannot look up remote revision; remote repository does not > > support the 'lookup' capability! > > > $ hg id http://hg.dillo.org/dillo > f4d5923de127 > > Greetings > Andreas Kemnade Thanks ! Ohloh is now on track. http://www.ohloh.net/p/dillo Current Project Cost (for a rewrite from scratch): $605.304 -- By by ... Detlef

March 25, 2009

[patch] Configurable key bindings

by jcid＠dillo.org

On Wed, Mar 25, 2009 at 04:46:33PM +0000, corvid wrote: > Jorge wrote: > > On Wed, Mar 25, 2009 at 04:20:19PM +0000, corvid wrote: > > > Jorge wrote: > > > > - Removed a_Prefs_freeall because it was not used anywhere. > > > > > > Should we rip out all of the *_freeall()s? > > > > Ooops! It slipped. > > > > The idea of those functions is to free memory there. > > They don't harm when empty. Let's keep them until something > > better springs up. > > Should we add calls to them like in dillo1 and get them working, then? Yes, that'd be good. Note that those functions are called at exit time. They were added long ago to help check for memory leaks. BTW, it'd be good to have some memory usage data for dillo-2.1. Something that can be put in a web page: e.g. a table with some explanations, on how dillo-2.1 compares with dillo-0.8.6 and with a big browser. IIRC sometime ago we made tests with a 13MB page, and the notion of dillo2 having near half the memory footprint of dillo1 came from there. We need to show some numbers and how we got them. Note: I remmeber having an awful memory footprint on 64bit Ubuntu. It didn't happen with 32bit. What's the current status, I don't know. -- Cheers Jorge.-

March 25, 2009

bug tracker doesn't work with dillo?

by corvid＠lavabit.com

Johannes wrote > On Wed, Mar 25, 2009 at 12:37:54PM -0400, Jorge Arellano Cid wrote: > > On Wed, Mar 25, 2009 at 05:19:48PM +0100, Hofmann Johannes wrote: > > > On Wed, Mar 25, 2009 at 08:33:28AM -0400, Jorge Arellano Cid wrote: > > > > On Wed, Mar 25, 2009 at 01:21:25AM +0100, Joerg Sonnenberger wrote: > > > > > On Wed, Mar 25, 2009 at 12:03:05AM +0000, corvid wrote: > > > > > > Jorge wrote: > > > > > > > Skimming the code it looks like the cast to long for int is > > > > > > > the way to go. If a: > > > > > > > > > > > > > > - URL_DATA(url)->len, content_type->str, > > > > > > > + (long)URL_DATA(url)->len, content_type->str, > > > > > > > > > > > > > > solves it. I'd commit it and let the explanation come after > > > > > > > the patch. > > > > > > > > > > > > I was thinking of adding long casts for the Content-Length headers > > > > > > in file.c as well. Sound good? > > > > > > > > > > Shouldn't that be (s)size_t? > > > > > > > > The parameter is specified as %ld, so long seems OK. > > > > > > I think Joerg is suggesting to switch the len field of struct Dstr > > > to size_t/ssize_t and to use this consistently (e.g. using %zd for > > > printing it). > > > Standard string functions also use size_t for string length. > > > > It took a long way to define 'len' as int. I wouldn't awake > > that dragon. > > Ah ok. I will browse CVS history a bit :) All right, then. I'll put a (long) in http.c and life will be pleasant.

March 25, 2009

bug tracker doesn't work with dillo?

by Johannes.Hofmann＠gmx.de

On Wed, Mar 25, 2009 at 12:37:54PM -0400, Jorge Arellano Cid wrote: > On Wed, Mar 25, 2009 at 05:19:48PM +0100, Hofmann Johannes wrote: > > On Wed, Mar 25, 2009 at 08:33:28AM -0400, Jorge Arellano Cid wrote: > > > On Wed, Mar 25, 2009 at 01:21:25AM +0100, Joerg Sonnenberger wrote: > > > > On Wed, Mar 25, 2009 at 12:03:05AM +0000, corvid wrote: > > > > > Jorge wrote: > > > > > > Skimming the code it looks like the cast to long for int is > > > > > > the way to go. If a: > > > > > > > > > > > > - URL_DATA(url)->len, content_type->str, > > > > > > + (long)URL_DATA(url)->len, content_type->str, > > > > > > > > > > > > solves it. I'd commit it and let the explanation come after > > > > > > the patch. > > > > > > > > > > I was thinking of adding long casts for the Content-Length headers > > > > > in file.c as well. Sound good? > > > > > > > > Shouldn't that be (s)size_t? > > > > > > The parameter is specified as %ld, so long seems OK. > > > > I think Joerg is suggesting to switch the len field of struct Dstr > > to size_t/ssize_t and to use this consistently (e.g. using %zd for > > printing it). > > Standard string functions also use size_t for string length. > > It took a long way to define 'len' as int. I wouldn't awake > that dragon. Ah ok. I will browse CVS history a bit :) Cheers, Johannes

March 25, 2009

[patch] Configurable key bindings

by corvid＠lavabit.com

Jorge wrote: > On Wed, Mar 25, 2009 at 04:20:19PM +0000, corvid wrote: > > Jorge wrote: > > > - Removed a_Prefs_freeall because it was not used anywhere. > > > > Should we rip out all of the *_freeall()s? > > Ooops! It slipped. > > The idea of those functions is to free memory there. > They don't harm when empty. Let's keep them until something > better springs up. Should we add calls to them like in dillo1 and get them working, then?

March 25, 2009

[patch] Configurable key bindings

by jcid＠dillo.org

On Wed, Mar 25, 2009 at 04:20:19PM +0000, corvid wrote: > Jorge wrote: > > - Removed a_Prefs_freeall because it was not used anywhere. > > Should we rip out all of the *_freeall()s? Ooops! It slipped. The idea of those functions is to free memory there. They don't harm when empty. Let's keep them until something better springs up. -- Cheers Jorge.-

March 25, 2009

bug tracker doesn't work with dillo?

by Johannes.Hofmann＠gmx.de

On Wed, Mar 25, 2009 at 08:33:28AM -0400, Jorge Arellano Cid wrote: > On Wed, Mar 25, 2009 at 01:21:25AM +0100, Joerg Sonnenberger wrote: > > On Wed, Mar 25, 2009 at 12:03:05AM +0000, corvid wrote: > > > Jorge wrote: > > > > Skimming the code it looks like the cast to long for int is > > > > the way to go. If a: > > > > > > > > - URL_DATA(url)->len, content_type->str, > > > > + (long)URL_DATA(url)->len, content_type->str, > > > > > > > > solves it. I'd commit it and let the explanation come after > > > > the patch. > > > > > > I was thinking of adding long casts for the Content-Length headers > > > in file.c as well. Sound good? > > > > Shouldn't that be (s)size_t? > > The parameter is specified as %ld, so long seems OK. I think Joerg is suggesting to switch the len field of struct Dstr to size_t/ssize_t and to use this consistently (e.g. using %zd for printing it). Standard string functions also use size_t for string length. Cheers, Johannes

March 25, 2009

[patch] Configurable key bindings

by corvid＠lavabit.com

Jorge wrote: > - Removed a_Prefs_freeall because it was not used anywhere. Should we rip out all of the *_freeall()s?

March 25, 2009

[patch] Configurable key bindings

by jcid＠dillo.org

Hi Tim, On Mon, Mar 09, 2009 at 04:54:57PM +0100, Tim Nieradzik wrote: > Here is an updated version of the patch. It aims to be fully > backward compatible. You do not need to change anything in your > dillorc (put the key bindings into ~/.dillo/keysrc). Good. > Changes: > - Ported src/dir\.[ch] to C++ (now called src/paths\.(cc|hh)). > - Split src/prefs.c (parser is now in src/prefsparser.c). > - Changed method names in src/dillo.cc to use camel case. > - Added meta-modifier and function keys F10-F12. > - Fixed some inconsistent white spaces. > - Shortened some license headers. > - Key bindings are to be defined in keysrc (previously dillorc). > - Minor code cleanups such as using "TODO:" instead of "\todo". > - Removed a_Prefs_freeall because it was not used anywhere. After giving a couple of read-passes to the patch, and considering that we still have some time before April (when I'll have time to focus on the release), we can merge this long patch in small independent chunks. Please separate them into different patch files. For instance: Simple ones: - Changed method names in src/dillo.cc to use camel case. - Fixed some inconsistent white spaces. - Shortened some license headers. - Minor code cleanups such as using "TODO:" instead of "\todo". - Removed a_Prefs_freeall because it was not used anywhere. Refactors: - Split src/prefs.c (parser is now in src/prefsparser.c). Core of it: - Key bindings are to be defined in keysrc (previously dillorc). - Added meta-modifier and function keys F10-F12. > PS: I would like to port some C files to C++ in order to achieve > more consistency. What is your opinion on this? As explained before. Not unless we're forced or there's a compelling reason. For instance I'd decline this: - Ported src/dir\.[ch] to C++ (now called src/paths\.(cc|hh)). (unless there's a strong reason I've not seen). -- Cheers Jorge.-

March 25, 2009

bug tracker doesn't work with dillo?

by jcid＠dillo.org

On Wed, Mar 25, 2009 at 12:03:05AM +0000, corvid wrote: > Jorge wrote: > > Skimming the code it looks like the cast to long for int is > > the way to go. If a: > > > > - URL_DATA(url)->len, content_type->str, > > + (long)URL_DATA(url)->len, content_type->str, > > > > solves it. I'd commit it and let the explanation come after > > the patch. > > I was thinking of adding long casts for the Content-Length headers > in file.c as well. Sound good? Sure, but after the test is known to work OK. -- Cheers Jorge.-

March 25, 2009

bug tracker doesn't work with dillo?

by jcid＠dillo.org

On Wed, Mar 25, 2009 at 01:21:25AM +0100, Joerg Sonnenberger wrote: > On Wed, Mar 25, 2009 at 12:03:05AM +0000, corvid wrote: > > Jorge wrote: > > > Skimming the code it looks like the cast to long for int is > > > the way to go. If a: > > > > > > - URL_DATA(url)->len, content_type->str, > > > + (long)URL_DATA(url)->len, content_type->str, > > > > > > solves it. I'd commit it and let the explanation come after > > > the patch. > > > > I was thinking of adding long casts for the Content-Length headers > > in file.c as well. Sound good? > > Shouldn't that be (s)size_t? The parameter is specified as %ld, so long seems OK. Now the number of parameters is relevant (quite irregular). > At least one vendor was smart enough to > produce a 64bit platform with long != ssize_t and support for files > larger than 32bit sounds highly useful... I'd like to have the result of the suggested test. -- Cheers Jorge.-

March 25, 2009

bug tracker doesn't work with dillo?

by corvid＠lavabit.com

Joerg wrote: > On Wed, Mar 25, 2009 at 12:03:05AM +0000, corvid wrote: > > Jorge wrote: > > > Skimming the code it looks like the cast to long for int is > > > the way to go. If a: > > > > > > - URL_DATA(url)->len, content_type->str, > > > + (long)URL_DATA(url)->len, content_type->str, > > > > > > solves it. I'd commit it and let the explanation come after > > > the patch. > > > > I was thinking of adding long casts for the Content-Length headers > > in file.c as well. Sound good? > > Shouldn't that be (s)size_t? At least one vendor was smart enough to > produce a 64bit platform with long != ssize_t and support for files > larger than 32bit sounds highly useful... Well, you know these issues better than I do. These two cases use %ld currently. One is given a size_t, and one is given an off_t.

March 25, 2009

bug tracker doesn't work with dillo?

by joerg.sonnenberger＠web.de

On Wed, Mar 25, 2009 at 12:03:05AM +0000, corvid wrote: > Jorge wrote: > > Skimming the code it looks like the cast to long for int is > > the way to go. If a: > > > > - URL_DATA(url)->len, content_type->str, > > + (long)URL_DATA(url)->len, content_type->str, > > > > solves it. I'd commit it and let the explanation come after > > the patch. > > I was thinking of adding long casts for the Content-Length headers > in file.c as well. Sound good? Shouldn't that be (s)size_t? At least one vendor was smart enough to produce a 64bit platform with long != ssize_t and support for files larger than 32bit sounds highly useful... Joerg

March 25, 2009

Re: Mac OS X Developer

by corvid＠lavabit.com

That would be terrific to get OS X straightened out...

March 25, 2009

bug tracker doesn't work with dillo?

by corvid＠lavabit.com

Jorge wrote: > Skimming the code it looks like the cast to long for int is > the way to go. If a: > > - URL_DATA(url)->len, content_type->str, > + (long)URL_DATA(url)->len, content_type->str, > > solves it. I'd commit it and let the explanation come after > the patch. I was thinking of adding long casts for the Content-Length headers in file.c as well. Sound good?

March 25, 2009

bug tracker doesn't work with dillo?

by jcid＠dillo.org

On Mon, Mar 23, 2009 at 11:04:45PM -0600, Scott Scriven wrote: > * Scott Scriven <dillo-dev(a)toykeeper.net> wrote: > > The first bad revision is: > > changeset: 491:96a14e974cfb > > Some extra details... when I enable the MSG() call, this is what > I get: > > r490: > Query: {POST /paste/paste.php HTTP/1.1\x0D > Connection: close\x0D > Accept-Charset: utf-8,*;q=0.8\x0D > Accept-Encoding: gzip\x0D > Host: rafb.net\x0D > Referer: http://rafb.net/\x0D > User-Agent: Dillo/2.0\x0D > Content-Length: 53\x0D > Content-Type: application/x-www-form-urlencoded\x0D > Cookie2: $Version="1"\x0D > Cookie: uid=foo; $Path=/paste/; $Domain=rafb.net\x0D > \x0D > lang=C%2B%2B&nick=foo&desc=r490+works&text=r490+works} > > r491: > Query: {POST /paste/paste.php HTTP/1.1\x0D > Connection: close\x0D > Accept-Charset: utf-8,*;q=0.8\x0D > Accept-Encoding: gzip\x0D > Host: rafb.net\x0D > Referer: http://rafb.net/\x0D > User-Agent: Dillo/2.0\x0D > Content-Length: 47966194761781\x0D > Content-Type: application/x-www-form-urlencoded\x0D > Cookie2: $Version="1"\x0D > Cookie: uid=foo; $Path=/paste/; $Domain=rafb.net\x0D > \x0D > lang=C%2B%2B&nick=foo&desc=r491+fails&text=r491+fails} > > So, it looks like the content-length is definitely the issue. I > just don't see how it's getting changed. Skimming the code it looks like the cast to long for int is the way to go. If a: - URL_DATA(url)->len, content_type->str, + (long)URL_DATA(url)->len, content_type->str, solves it. I'd commit it and let the explanation come after the patch. -- Cheers Jorge.-

March 24, 2009

Re: Mac OS X Developer

by jcid＠dillo.org

On Sun, Mar 22, 2009 at 04:10:15PM -0300, Nicol?s Manuel Luna wrote: > Hello! My name is Nicolas Luna and I'm from Argentina. I was reading in > your website that you need Mac OS X Developer. Well, I've recently > migrated to this system and I use dillo for a long time (I used it in > Slackware). > I want to contribute anything as posible. I know how to compile, install > dependencies and I know some of C. > If you want me, say me what can I do. I love this browser :D. Great! Currently Dillo works in OSX but with some glitches. For instance, sometimes it is necessary to move the mouse over the rendering area to get a refresh. Sometimes buttons don't draw. I don't know what may be fixed/workarounded in Dillo and what may be FLTK2's fault. So the first you can do is to get it to run in OSX and to start investigating the problems. If you get stuck, you can ask in fltk general or dillo-dev (BTW, please subscribe to dillo-dev). Help is very welcomed. -- Cheers Jorge.-

March 24, 2009

MINIX3 wants to port Dillo for GSOC...

by jcid＠dillo.org

On Sun, Mar 22, 2009 at 06:56:08PM +0000, corvid wrote: > ..in case that should interest anyone out there. > (http://www.minix3.org/soc-2009/) > > They have fltk2, libiconv, openssl, zlib, wget, libpng, libjpeg. > Not sure about pthreads for DNS... Yes, after some emails with AST sometime ago, I told him I could give it a try after the dillo-2.1 release is done. -- Cheers Jorge.-

March 24, 2009

bookmark dpi - cleanups

by jcid＠dillo.org

On Fri, Mar 20, 2009 at 07:36:28PM +0100, Justus Winter wrote: > Hey Folks :) > > the select an operation header line in dpi:/bm/modify contains a number > of no breaking spaces that prevented dillo from wrapping the text making > the page somewhat hard to use on a small screen (the freerunners display > is 480 pixels wide). The third patch fixes this problem. I couldn't help > to clean up some optical inconsistencies and a html bug warning while > fixing the original problem. Good! All committed. -- Cheers Jorge.-

March 24, 2009

bug tracker doesn't work with dillo?

by corvid＠lavabit.com

Scott wrote: > * corvid <corvid(a)lavabit.com> wrote: > > Does using %d or casting the length to a long > > change anything? > > Yes, either one resolves the issue. :) > > > It doesn't seem like adding a ptr arg should > > be able to do anything to alignment, but > > then I don't know what goes on in the > > bowels of the varargs stuff. > > It looks like the alignment was probably off all along, and > adding a parameter just revealed an old bug. I found that simply > adding a "%s" to the format string, with an empty "" as its > parameter, was enough to trigger the problem. > > More generally, I found that it works if I use an even number of > variables in format string, but it fails with an odd number. So, > I think the compiler is probably padding something and the "%ld" > gets the extra zero bits it needs from the padding. Do you have any problems with - reading local files - getting the tiny error pages for nonexistent local files? These cases in dpi/file.c also use %ld for content length, passing in an off_t and a size_t.

March 24, 2009

compiling error on FreeBSD 6.4

by Johannes.Hofmann＠gmx.de

On Tue, Mar 24, 2009 at 08:42:56PM +0900, furaisanjin wrote: > 2009/3/24 Hofmann Johannes <Johannes.Hofmann(a)gmx.de>: > > Oh, maybe getc is a macro in FreeBSD? Can you please try attached > > patch that renames the getc() / ungetc() methods to something > > non-standard. > > Thank you. The patch works fine. I can compile dillo and it's working OK. Committed. Thanks for testing, Johannes

March 24, 2009

compiling error on FreeBSD 6.4

by furaisanjin＠gmail.com

2009/3/24 Hofmann Johannes <Johannes.Hofmann(a)gmx.de>: > Oh, maybe getc is a macro in FreeBSD? Can you please try attached > patch that renames the getc() / ungetc() methods to something > non-standard. Thank you. The patch works fine. I can compile dillo and it's working OK. Regards, furaisanjin

March 24, 2009

bug tracker doesn't work with dillo?

by dillo-dev＠toykeeper.net

* corvid <corvid(a)lavabit.com> wrote: > Does using %d or casting the length to a long > change anything? Yes, either one resolves the issue. :) > It doesn't seem like adding a ptr arg should > be able to do anything to alignment, but > then I don't know what goes on in the > bowels of the varargs stuff. It looks like the alignment was probably off all along, and adding a parameter just revealed an old bug. I found that simply adding a "%s" to the format string, with an empty "" as its parameter, was enough to trigger the problem. More generally, I found that it works if I use an even number of variables in format string, but it fails with an odd number. So, I think the compiler is probably padding something and the "%ld" gets the extra zero bits it needs from the padding. -- Scott

March 24, 2009

[bug]: more CSS margin problems

by onepoint＠starurchin.org

On Tue, Mar 24, 2009 at 08:34:26AM +0100, Hofmann Johannes wrote: > On Sun, Mar 22, 2009 at 07:13:32AM +0000, Jeremy Henty wrote: > > On Sat, Mar 21, 2009 at 10:25:32AM +0100, Hofmann Johannes wrote: > > > > > Maybe we should just disable negative margins for now. [...] > > > Other ideas? > > > > No ideas, I'm afraid. I haven't really looked at Dillo's CSS or > > layout code. > > Ok, I've disabled negative margins for now. And it works very nicely. Excellent! Regards, Jeremy Henty

March 24, 2009

[bug]: more CSS margin problems

by Johannes.Hofmann＠gmx.de

On Sun, Mar 22, 2009 at 07:13:32AM +0000, Jeremy Henty wrote: > On Sat, Mar 21, 2009 at 10:25:32AM +0100, Hofmann Johannes wrote: > > > It seems that dw/* is not designed to handle overlapping widgets. > > Maybe we should just disable negative margins for now. Or at least > > ensure that only margins overlap but not widget contents. Other > > ideas? > > No ideas, I'm afraid. I haven't really looked at Dillo's CSS or > layout code. Ok, I've disabled negative margins for now. Cheers, Johannes

March 24, 2009

compiling error on FreeBSD 6.4

by Johannes.Hofmann＠gmx.de

Hi, On Tue, Mar 24, 2009 at 08:11:00AM +0900, furaisanjin wrote: > Hi all. > > I got compiling error on FreeBSD 6.4. I pulled and updated this > morning and then got this error. > > gmake[3]: Entering directory `/tmp/disk1/src/css/dillo/src' > if g++ -DHAVE_CONFIG_H -I. -I. -I.. > -DDILLORC_SYS='"/usr/local/etc/dillorc"' -I/usr/local/include -I.. > -I/usr/local/include/libpng -O2 -fno-strict-aliasing -pipe > -I/usr/local/include -I/usr/local/include/freetype2 > -I/usr/local/include -I/usr/X11R6/include -Wno-non-virtual-dtor -g -O2 > -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT web.o -MD > -MP -MF ".deps/web.Tpo" -c -o web.o web.cc; \ > then mv -f ".deps/web.Tpo" ".deps/web.Po"; else rm -f > ".deps/web.Tpo"; exit 1; fi > In file included from styleengine.hh:7, > from web.cc:25: > cssparser.hh:27: error: expected unqualified-id before '!' token > cssparser.hh:27: error: expected `)' before '!' token > gmake[3]: *** [web.o] Error 1 > gmake[3]: Leaving directory `/tmp/disk1/src/css/dillo/src' > gmake[2]: *** [all-recursive] Error 1 > gmake[2]: Leaving directory `/tmp/disk1/src/css/dillo/src' > gmake[1]: *** [all-recursive] Error 1 > gmake[1]: Leaving directory `/tmp/disk1/src/css/dillo' > gmake: *** [all] Error 2 > > I have no idea when this happned. Oh, maybe getc is a macro in FreeBSD? Can you please try attached patch that renames the getc() / ungetc() methods to something non-standard. Regards, Johannes

March 24, 2009

bug tracker doesn't work with dillo?

by dillo-dev＠toykeeper.net

* Scott Scriven <dillo-dev(a)toykeeper.net> wrote: > The first bad revision is: > changeset: 491:96a14e974cfb Some extra details... when I enable the MSG() call, this is what I get: r490: Query: {POST /paste/paste.php HTTP/1.1\x0D Connection: close\x0D Accept-Charset: utf-8,*;q=0.8\x0D Accept-Encoding: gzip\x0D Host: rafb.net\x0D Referer: http://rafb.net/\x0D User-Agent: Dillo/2.0\x0D Content-Length: 53\x0D Content-Type: application/x-www-form-urlencoded\x0D Cookie2: $Version="1"\x0D Cookie: uid=foo; $Path=/paste/; $Domain=rafb.net\x0D \x0D lang=C%2B%2B&nick=foo&desc=r490+works&text=r490+works} r491: Query: {POST /paste/paste.php HTTP/1.1\x0D Connection: close\x0D Accept-Charset: utf-8,*;q=0.8\x0D Accept-Encoding: gzip\x0D Host: rafb.net\x0D Referer: http://rafb.net/\x0D User-Agent: Dillo/2.0\x0D Content-Length: 47966194761781\x0D Content-Type: application/x-www-form-urlencoded\x0D Cookie2: $Version="1"\x0D Cookie: uid=foo; $Path=/paste/; $Domain=rafb.net\x0D \x0D lang=C%2B%2B&nick=foo&desc=r491+fails&text=r491+fails} So, it looks like the content-length is definitely the issue. I just don't see how it's getting changed. -- Scott

March 24, 2009

bug tracker doesn't work with dillo?

by dillo-dev＠toykeeper.net

* corvid <corvid(a)lavabit.com> wrote: > Oh, also, did 2.0 work for you? Yes. But how about something more specific... I ran 'hg bisect' on it and here is the result: The first bad revision is: changeset: 491:96a14e974cfb tag: 2.1-noCss user: corvid <corvid(a)lavabit.com> date: Thu Jan 15 18:33:04 2009 -0300 summary: Added the "http_language" dillorc option for setting HTTP's Accept-Language. The diff for that revision doesn't really tell me why it broke then... nothing obvious stands out. But r490 works and r491 doesn't. Maybe you'll see something I don't. :) -- Scott

March 24, 2009

bug tracker doesn't work with dillo?

by corvid＠lavabit.com

Scott wrote: > * corvid <corvid(a)lavabit.com> wrote: > > If you go to src/IO/http.c and at the bottom of > > a_Http_make_query_str() change the _MSG to MSG, what does it > > print when you make the request? > > This is the terminal output after hitting 'submit': > > DilloHtmlForm::eventHandler > Nav_open_url: new url='http://rafb.net/paste/paste.php' > Connecting to 216.22.48.130 > Query: {POST /paste/paste.php HTTP/1.1\x0D > Connection: close\x0D > Accept-Charset: utf-8,*;q=0.8\x0D > Accept-Encoding: gzip\x0D > Host: rafb.net\x0D > Referer: http://rafb.net/\x0D > User-Agent: Dillo/2.0\x0D > Content-Length: 46952582479933\x0D > Content-Type: application/x-www-form-urlencoded\x0D > Cookie2: $Version="1"\x0D > \x0D > lang=Plain+Text&nick=nickname&desc=description&text=some+text} > > That content-length header looks a bit off... maybe the code > expects a 32-bit integer but gets a 64-bit integer instead? > > The length specified is 0x2ab40000003d, but the actual content is > only 0x3d. So, it sure looks like an integer size issue. I'm guessing that URL_DATA(url)->len has the right value since the dStr_append_l() didn't lose its mind, so... does it help if the "Content-Length: %ld\r\n" is changed to "Content-Length: %d\r\n" a bit earlier in a_Http_make_query_str()? I'm not sure that would necessarily fix it, but I also don't see what purpose the 'l' serves if a Dstr's len is a plain old int.

March 24, 2009

bug tracker doesn't work with dillo?

by dillo-dev＠toykeeper.net

* corvid <corvid(a)lavabit.com> wrote: > If you go to src/IO/http.c and at the bottom of > a_Http_make_query_str() change the _MSG to MSG, what does it > print when you make the request? This is the terminal output after hitting 'submit': DilloHtmlForm::eventHandler Nav_open_url: new url='http://rafb.net/paste/paste.php' Connecting to 216.22.48.130 Query: {POST /paste/paste.php HTTP/1.1\x0D Connection: close\x0D Accept-Charset: utf-8,*;q=0.8\x0D Accept-Encoding: gzip\x0D Host: rafb.net\x0D Referer: http://rafb.net/\x0D User-Agent: Dillo/2.0\x0D Content-Length: 46952582479933\x0D Content-Type: application/x-www-form-urlencoded\x0D Cookie2: $Version="1"\x0D \x0D lang=Plain+Text&nick=nickname&desc=description&text=some+text} That content-length header looks a bit off... maybe the code expects a 32-bit integer but gets a 64-bit integer instead? The length specified is 0x2ab40000003d, but the actual content is only 0x3d. So, it sure looks like an integer size issue. -- Scott

March 24, 2009

compiling error on FreeBSD 6.4

by furaisanjin＠gmail.com

Hi all. I got compiling error on FreeBSD 6.4. I pulled and updated this morning and then got this error. gmake[3]: Entering directory `/tmp/disk1/src/css/dillo/src' if g++ -DHAVE_CONFIG_H -I. -I. -I.. -DDILLORC_SYS='"/usr/local/etc/dillorc"' -I/usr/local/include -I.. -I/usr/local/include/libpng -O2 -fno-strict-aliasing -pipe -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include -I/usr/X11R6/include -Wno-non-virtual-dtor -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT web.o -MD -MP -MF ".deps/web.Tpo" -c -o web.o web.cc; \ then mv -f ".deps/web.Tpo" ".deps/web.Po"; else rm -f ".deps/web.Tpo"; exit 1; fi In file included from styleengine.hh:7, from web.cc:25: cssparser.hh:27: error: expected unqualified-id before '!' token cssparser.hh:27: error: expected `)' before '!' token gmake[3]: *** [web.o] Error 1 gmake[3]: Leaving directory `/tmp/disk1/src/css/dillo/src' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/tmp/disk1/src/css/dillo/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/tmp/disk1/src/css/dillo' gmake: *** [all] Error 2 I have no idea when this happned. Regards, furaisanjin

March 24, 2009

bug tracker doesn't work with dillo?

by corvid＠lavabit.com

Scott wrote: > * corvid <corvid(a)lavabit.com> wrote: > > I just tried adding bug entries as a test, > > and everything worked fine for me. > > Odd. I tried three times before mentioning it. > > FWIW, I'm using dillo r998 from http://hg.dillo.org/dillo, > configured with '--prefix=/usr --enable-ssl --enable-ipv6'. The > OS is Ubuntu 7.10 / x86_64. > > I tried a fresh build just now (tip, r1017) and it failed again. > In case it's dependent on the data submitted, here's what I sent: > > http://www.dillo.org/bugtrack/Dinsert.html > Inside dillo 'current' using 'Linux' with 'glibc2' > I found a 'soft error' at 'run time' causing a 'misbehavior' > Comments: > Testing whether dillo can file bugs in dillo.org's database. > Please delete. > HTReproduce: Test, please delete. > Worked by: nobody > Submitter: dillo(a)toykeeper.net > > I get the same error at other sites too. For example: > > http://rafb.net/paste/ > Language: Plain Text > Nickname: foo > Description: foo > Text: foo > > The error is nearly identical: > > Request Entity Too Large > > The requested resource > /paste/paste.php > does not allow request data with POST requests, or the amount > of data provided in the request exceeds the capacity limit. > > Additionally, a 413 Request Entity Too Large error was > encountered while trying to use an ErrorDocument to handle > the request. > > Any idea why it works for you but fails for me? Different > version, different build options, different platform... If you go to src/IO/http.c and at the bottom of a_Http_make_query_str() change the _MSG to MSG, what does it print when you make the request?

March 23, 2009

bug tracker doesn't work with dillo?

by dillo-dev＠toykeeper.net

* corvid <corvid(a)lavabit.com> wrote: > I just tried adding bug entries as a test, > and everything worked fine for me. Odd. I tried three times before mentioning it. FWIW, I'm using dillo r998 from http://hg.dillo.org/dillo, configured with '--prefix=/usr --enable-ssl --enable-ipv6'. The OS is Ubuntu 7.10 / x86_64. I tried a fresh build just now (tip, r1017) and it failed again. In case it's dependent on the data submitted, here's what I sent: http://www.dillo.org/bugtrack/Dinsert.html Inside dillo 'current' using 'Linux' with 'glibc2' I found a 'soft error' at 'run time' causing a 'misbehavior' Comments: Testing whether dillo can file bugs in dillo.org's database. Please delete. HTReproduce: Test, please delete. Worked by: nobody Submitter: dillo(a)toykeeper.net I get the same error at other sites too. For example: http://rafb.net/paste/ Language: Plain Text Nickname: foo Description: foo Text: foo The error is nearly identical: Request Entity Too Large The requested resource /paste/paste.php does not allow request data with POST requests, or the amount of data provided in the request exceeds the capacity limit. Additionally, a 413 Request Entity Too Large error was encountered while trying to use an ErrorDocument to handle the request. Any idea why it works for you but fails for me? Different version, different build options, different platform... -- Scott

March 23, 2009

bug tracker doesn't work with dillo?

by corvid＠lavabit.com

Scott wrote: > I went to add a bug to the database today and found that it > always returns errors when I attempt to file bugs using dillo. I > ended up having to use firefox instead. > > The specific error is: > > Request Entity Too Large > > The requested resource > /cgi-bin/bugtrack/Dillo_insert.cgi > does not allow request data with POST requests, or the amount > of data provided in the request exceeds the capacity limit. > > I checked with 'wc' and the data wasn't even half the limit. So, > dillo is behaving somehow incorrectly. > > I'm writing here about it instead of filing a new bug because > even the short description above is twice as big as the bug > tracker allows... and it has no facilities for discussion or > notification. I just tried adding bug entries as a test, and everything worked fine for me.

March 23, 2009

bug tracker doesn't work with dillo?

by dillo-dev＠toykeeper.net

I went to add a bug to the database today and found that it always returns errors when I attempt to file bugs using dillo. I ended up having to use firefox instead. The specific error is: Request Entity Too Large The requested resource /cgi-bin/bugtrack/Dillo_insert.cgi does not allow request data with POST requests, or the amount of data provided in the request exceeds the capacity limit. I checked with 'wc' and the data wasn't even half the limit. So, dillo is behaving somehow incorrectly. I'm writing here about it instead of filing a new bug because even the short description above is twice as big as the bug tracker allows... and it has no facilities for discussion or notification. -- Scott

March 23, 2009

http authentication: http digest

by corvid＠lavabit.com

Justus wrote: > * rfc2617 is a bit fuzzy about the quoted strings in the challenge. > strings are enclosed in double quotes, but it is not specified > (or I overlooked it..) how double quotes within this string > should be escaped. I intuitively escaped them with a \, and > apache2 plays along nicely. So does my code. Funny thing is, > neither one of the mayor browsers (I tested ff, epiphany, opera, > konqueror, ie6) can cope with realms containing quotes... > Am I missing something here? I think that's right. Section 1.1 says that it relies on HTTP/1.1 for grammar stuff, and if I go there, I find: quoted-string = ( <"> *(qdtext | quoted-pair ) <"> ) qdtext = <any TEXT except <">> quoted-pair = "\" CHAR > * http digest can provide integrity protection for the request body > by computing a hash over the request body, but I have no pointer to > the request body, only the request URL. We might need to pass the > whole request object (is there such a thing?) to the auth code instead > of just the url. The code is there, just the pointer is missing. The > code in auth.c will select the method without integrity protection for > now, hoping that the server will accept both auth and auth-int. It sounds like entity-body is what you get _after_ dealing with the transfer coding (chunked) but _before_ dealing with the content coding (gzip). How annoying. It sounds like it would be necessary to hack some special field into the cache entry to be used when we see a WWW-Authenticate header, at least if it was gzipped...

March 23, 2009

http authentication: http digest

by 4winter＠informatik.uni-hamburg.de

Hey folks :) attached is a patch that implements http digest authentication. Some thoughs: * add-md5.patch adds md5.{c,h}, a BSD licensed md5 implementation by L. Peter Deutsch from [0] * the digest logic resides in digest.c * I adapted a lot of challenge parsing code from Jeremys basic auth to better suit my needs, sorry for the big patch, but this reduces code duplication (even mailman thinks the patch is too big >,<) * rfc2617 is a bit fuzzy about the quoted strings in the challenge. strings are enclosed in double quotes, but it is not specified (or I overlooked it..) how double quotes within this string should be escaped. I intuitively escaped them with a \, and apache2 plays along nicely. So does my code. Funny thing is, neither one of the mayor browsers (I tested ff, epiphany, opera, konqueror, ie6) can cope with realms containing quotes... Am I missing something here? * http digest can provide integrity protection for the request body by computing a hash over the request body, but I have no pointer to the request body, only the request URL. We might need to pass the whole request object (is there such a thing?) to the auth code instead of just the url. The code is there, just the pointer is missing. The code in auth.c will select the method without integrity protection for now, hoping that the server will accept both auth and auth-int. * there is a memory leak (well, at least one that I am aware of) in a_Auth_get_auth_str (grep 'this leaks memory' auth.c). This function is called for each request dillo makes to a host using http auth. For basic authentication the challenge response is always the same, so a reference to that string is stored in the realm and it is freed with its destruction. For digest authentication a different response is needed for each request (the request uri and a nonce_counter needs to be updated), so a new string has to be generated for each request. This should be easily fixable, but I didn't looked into that yet (need to touch the callers code). That's it :) feedback is welcome! Justus 0: http://sourceforge.net/project/showfiles.php?group_id=42360

March 23, 2009