Geändert: 20. 1. 2010, 21:25
Konqueror kicking ass again
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.