Recently I found a site with HTTP Content-Disposition header tests and their results. First that was only tested with Konqueror 3.5.8 from an ancient Knoppix CD, which the author quickly updated after I pointed him to the openSUSE 11.2 KDE Live CD. Nevertheless the results were still pretty bad, some things even got worse compared to 3.5.8. The attonlyucase and attwithasciifilenameucase tests are pretty stupid to fail.

So this is some basic technical stuff, includes collecting things from different RfCs, getting the implementation right etc., or to make a long story short: somethings that deserves my attraction ;) The other, simpler, but much more unlikely way to get my attention to such a problem would be some money (just in case *g*). Ok, anyway, the good news is: the current trunk is the best browser in this tests. Here is how the results would look like with the current trunk (previous results shamelessly stolen from the original site). I hope I can backport some or all of these fixes to 4.4.0 or 4.4.1.

Test Case Konqueror 4.3.1 Konqueror trunk (r1075763) Summary Content-Disposition: Disposition-Type Inline inlonly pass pass inlwithasciifilename pass (filename information not used) pass (filename information not always used) inlwithasciifilenamepdf pass (filename information not used) pass (filename information used) Content-Disposition: Disposition-Type Attachment attonly pass pass attonlyucase fail pass attwithasciifilename pass pass attwithasciifnescapedchar pass pass attwithfilenameandextparam pass pass attwithasciifilenameucase fail (filename parameter is ignored) pass attwithasciifilenamenq warn (accepts the unquoted value) warn (accepts the unquoted value) attwithisofnplain pass pass attwithutf8fnplain pass pass attwithfnrawpctenca pass pass attwithfnrawpctenclong pass pass attwithasciifilenamews1 pass pass attwithasciifilenamews2 pass pass Content-Disposition: Additional Parameters attcdate unsupported (seems to ignore the parameter) unsupported (seems to ignore the parameter) attmdate unsupported (seems to ignore the parameter) unsupported (seems to ignore the parameter) Content-Disposition: Disposition-Type Extension dispext fail (does not treat it as 'attachment') pass RFC2231 Encoding: Character Sets attwithisofn2231iso unsupported pass attwithfn2231utf8 unsupported pass attwithfn2231noc unsupported pass attwithfn2231utf8comp unsupported pass attwithfn2231utf8-bad unsupported warn (displays the raw octet sequence as if it was ISO-8859-1) attwithfn2231ws1 unsupported pass attwithfn2231ws2 unsupported pass attwithfn2231ws3 unsupported pass attwithfn2231quot unsupported pass attwithfn2231encmissing unsupported pass RFC2231 Encoding: Continuations attfncont unsupported pass attfncontenc unsupported pass attfncontlz unsupported pass attfncontnc unsupported pass attfnconts1 unsupported pass attfncontord unsupported pass RFC2231 Encoding: Fallback Behaviour attfnboth pass (picks the traditionally encoded value -- the one it understands) pass (picks the RFC2231 encoded value) attfnboth2 pass (picks the traditionally encoded value -- the one it understands) pass (picks the RFC2231 encoded value) RFC2047 Encoding attrfc2047token fail (decodes it anyway to "foo-ä.html") pass attrfc2047quoted fail (decodes it anyway to "foo-ä.html") pass

Update: the attwithfn2231noc testcase was added after I mentioned that particular unclarity.