Scott wrote:

* corvid <corvid@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@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?

Scott wrote:

* corvid <corvid@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.

Scott wrote:

* corvid <corvid@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.