- Dillo-dev - lists.mailman3.com

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

MINIX3 wants to port Dillo for GSOC...

by corvid＠lavabit.com

..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...

March 22, 2009

http authentication: shred passwords

by corvid＠lavabit.com

Justus wrote: > I've been working on http digest authentication (mostly done, needs some > more testing) and I noticed that sensitive information like passwords > aren't cleared before freeing the memory. > > I know this is kind of pointless for basic authentication since > realm->authentication holds the base64 encoded password anyway, but at > least it isn't stored in plain text. It is however very useful for the > http digest authentication which only stores the hashed password. > > There is a small problem with the attached patch (at least I think that > there is): it modifies a member variable of fltk::Input that is declared > const char *. I *think* that this does not cause any problems in > practice since the widget is destroyed shortly after this anyway and I > believe that doing this right requires patching fltk. What do you think? So far as I know (for whatever that's worth), it should be all right since the value wasn't set with static_text().

March 22, 2009

http authentication: shred passwords

by 4winter＠informatik.uni-hamburg.de

Skipped content of type multipart/mixed

March 22, 2009

[bug]: more CSS margin problems

by onepoint＠starurchin.org

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. Regards Jeremy Henty

March 22, 2009

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

by Johannes.Hofmann＠gmx.de

On Fri, Mar 20, 2009 at 07:05:24PM +0100, Andreas Kemnade wrote: > Hi, > > On Tue, 24 Feb 2009 20:21:52 +0100 > Detlef Riekenberg <wine.dev(a)web.de> wrote: > > > Hi. > > Thanks for working on Dillo. > > > > I tried to update the Dillo Project Page on Ohloh, > > but the the repository failed on the id command. > > > > ...$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 > Thanks Andreas!

March 21, 2009