bug tracker doesn't work with dillo?
* corvid <corvid@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@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
* Scott Scriven <dillo-dev@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
On Mon, Mar 23, 2009 at 11:04:45PM -0600, Scott Scriven wrote:
* Scott Scriven <dillo-dev@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.-
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?
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
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.
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.-
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
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.-
participants (5)
-
corvid＠lavabit.com -
dillo-dev＠toykeeper.net -
jcid＠dillo.org -
joerg.sonnenberger＠web.de -
Johannes.Hofmann＠gmx.de