Here is some information that might be useful for development:

I have a MediaWiki installation which I serve via Apache, all running on Linux. I intend to use Prince 8.0 to convert several hundred pages to one PDF file, accessing the pages all via "http://localhost/wiki/index.php5/Page_Title". The static 64-bit binary of Prince reports "error: The requested URL returned error: 400" and Apache's error_log contains messages of the form "error reading the headers, referer: xe8\x87\xe0\b\x18{\x02". I also observed that the Apache error_log messages sometimes contain weird substrings of some of my page names. Reducing the number of pages to download changes the subset of pages where that error occurs (it's stable, otherwise) but then Prince seems to get stuck and eats up all available memory (strace shows that it calls brk all the time).

Eventually I discovered that the dynamic 64-bit binaries runs absolutely flawlessly on a machine running Debian 6.0.3.

This suggests that the problem is in one or some of the library versions linked into the static binaries. Maybe, the stability could be enhanced by linking the static binaries on a Debian 6.0.3 system? (Oh, and yes, I do volunteer as a tester, even though that particular problem is now solved for me.)

Unfortunately there are issues with the curl library when statically linked, so we recommend the use of dynamically linked binaries wherever possible, with the statically linked binaries only used as a fallback when no other solution is available.

Aha. May I recommend to put a warning about the static binaries on the Download page?

I have reordered the binaries so that the dynamically linked packages are listed ahead of the statically linked packages on the download page.

My problems have re-surfaced: Before the 200 or so http:// pages I tried to prepend a file:// one. After playing around for a while I found that it works in debian wheezy/sid which uses libcurl 7.23.1 instead of 7.21.0. (I had to add libssl-0.9.8 and libcrypto-0.9.8.) Is this some problem that is known to have been fixed or is it tracked by the curl maintainers or is it worth investigating further?

A local file, on the same server? These should be loaded by Prince without any involvement of libcurl. What was the error message?

Sorry for being unclear: The local file was loaded fine, but the usual errors trying to get the HTTP files were coming back.

So using the dynamically linked packages, you get the error on one machine running a particular version of Debian and curl, but not on a different machine running a different version of Debian and curl? This does start to seem like a curl issue that has occurred in the past that we have not been able to track down. Especially if you are getting transient 400 errors that don't seem to be related to any obvious aspect of the input document. The tricky part is, how to narrow it down?

This is indeed tricky. It starts looking like the failures have to do with system's load.

Can you confirm that it only affects one particular version of curl? And which one?

Not really. All I know is that it works with 7.23.1 while I keep having these sporadic failures with 7.21.0.

Okay we may have a fix for this issue. If you would like to try it out, please email me (mikeday@yeslogic.com) and let me know which Prince package you installed, and I'll arrange an updated binary that hopefully will fix the problem.

Prince 8.1 is now available, and includes the fix for this issue. Thanks for your patience, it was a tough nut to crack!