March 2009 - Dillo-dev - lists.mailman3.com

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

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