- Dillo-dev - lists.mailman3.com

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