Dakons blog

Erstellt: 16. 1. 2010, 19:00
Geändert: 20. 1. 2010, 21:25

Konqueror kicking ass again

Tags:

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 CaseKonqueror 4.3.1Konqueror trunk (r1075763)
Summary 38% passes, 10% failures, 3% warnings, 46% unsupported 90% passes, 0% failures, 5% warnings, 5% unsupported
Content-Disposition: Disposition-Type Inlineinlonlypasspass
inlwithasciifilenamepass (filename information not used)pass (filename information not always used)
inlwithasciifilenamepdfpass (filename information not used)pass (filename information used)
Content-Disposition: Disposition-Type Attachmentattonlypasspass
attonlyucasefailpass
attwithasciifilenamepasspass
attwithasciifnescapedcharpasspass
attwithfilenameandextparampasspass
attwithasciifilenameucasefail (filename parameter is ignored)pass
attwithasciifilenamenqwarn (accepts the unquoted value)warn (accepts the unquoted value)
attwithisofnplainpasspass
attwithutf8fnplainpasspass
attwithfnrawpctencapasspass
attwithfnrawpctenclongpasspass
attwithasciifilenamews1passpass
attwithasciifilenamews2passpass
Content-Disposition: Additional Parametersattcdateunsupported (seems to ignore the parameter)unsupported (seems to ignore the parameter)
attmdateunsupported (seems to ignore the parameter)unsupported (seems to ignore the parameter)
Content-Disposition: Disposition-Type Extensiondispextfail (does not treat it as 'attachment')pass
RFC2231 Encoding: Character Setsattwithisofn2231isounsupportedpass
attwithfn2231utf8unsupportedpass
attwithfn2231nocunsupportedpass
attwithfn2231utf8compunsupportedpass
attwithfn2231utf8-badunsupportedwarn (displays the raw octet sequence as if it was ISO-8859-1)
attwithfn2231ws1unsupportedpass
attwithfn2231ws2unsupportedpass
attwithfn2231ws3unsupportedpass
attwithfn2231quotunsupportedpass
attwithfn2231encmissingunsupportedpass
RFC2231 Encoding: Continuationsattfncontunsupportedpass
attfncontencunsupportedpass
attfncontlzunsupportedpass
attfncontncunsupportedpass
attfnconts1unsupportedpass
attfncontordunsupportedpass
RFC2231 Encoding: Fallback Behaviourattfnbothpass (picks the traditionally encoded value -- the one it understands)pass (picks the RFC2231 encoded value)
attfnboth2pass (picks the traditionally encoded value -- the one it understands)pass (picks the RFC2231 encoded value)
RFC2047 Encodingattrfc2047tokenfail (decodes it anyway to "foo-ä.html")pass
attrfc2047quotedfail (decodes it anyway to "foo-ä.html")pass

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

Via: Fefe's blog
Anbieterkennzeichnung