Version: 3.4.1 (using KDE 3.4.1, Debian Package 4:3.4.1-1 (3.1)) Compiler: gcc version 3.3.6 (Debian 1:3.3.6-5) OS: Linux (i686) release 2.6.11.3 I go to http://www.bogaa.org/details/5081 and click on the torrent link in the "Download" line. This link points to http://www.bogaa.org/download.php?id=a7b22806424fdf69f8e2e4058b178296fae271f8 this URL returns a torrent file and a "Content-Disposition" header which tells konqueror to use a different name when saving this file. This new name is mccreesh: J.S. Bach etc. Now, instead of saving the file with this name, konqueror interprets mccreesh: as a protocol name and complains that it doesn't know about this protocol. This is wrong. Konqueror should just use the supplied filename verbatim (except for ignoring directory names). There are possible security implications: While konqueror blocks links on web pages that point to protocols deemed unsafe for web use it is not clear if konqueror checks this case too. This needs checking. Also, I'm using kget. Maybe the bug is in kget and not in konqueror.
This is the error message displayed (german locale): Prozess Aufruf des Ein/Ausgabe-Moduls nicht möglich. klauncher meldet: Unbekanntes Protokoll "mccreesh". kann nicht gestartet werden.
this must be a bug. A protocol should be like _protocol://_ , note the double slash i.e. http://domain ftp://ftpserver etc mccreesh: should not be interpreted as protocol. the mccreesh: is NOT a protocol, however the semicolon is a nasty thing because it is the drive letter indication for windoze. :) There is no mccreesh:\document and settings\username to store it. The semicolon is, when i'm right, forbidden in filenames using windoze.
Is there somewhere we can try to reproduce this problem? The link given originally no longer works (points to a domain squatting site)
On Tue, Sep 05, 2006 at 01:24:38PM -0000, Philip Rodrigues wrote: > > ------- Additional Comments From phil kde org 2006-09-05 15:24 ------- > Is there somewhere we can try to reproduce this problem? The link given originally no longer works (points to a domain squatting site) I just checked, the bug is still there. I believe it is in KGet. To reproduce, install the following PHP script on a web-server: <?php header ("Content-type: application/octet-string"); header ('Content-disposition: filename="mccreesh: testfile"'); echo "TEST\0TEST\n"; ?> Walter
I can partially reproduce on KDE 3.5.5 (without KGet): using Walter's testcase, I don't get an error message when I click on the file and select "Save as...", but it doesn't fill in the file name in the save dialogue. Without the colon, it does. With KGet, I get shown a "folder select" dialogue, then KGet complains about a "malformed url".
Uploaded the testcase to: http://test.confuego.org/107957.php I can still confirm parts of this bug. While I don't get errors about malformed URLs in either 3.5.9 or trunk r809039 (with and without kget) in none of the cases the filename was extracted correctly (either it's not filled at all or filled with the name of the script).
(In reply to comment #6) > Uploaded the testcase to: http://test.confuego.org/107957.php > > I can still confirm parts of this bug. While I don't get errors about malformed URLs in either 3.5.9 or trunk r809039 (with and without kget) in none of the cases the filename was extracted correctly (either it's not filled at all or filled with the name of the script). Konqueror's content-disposition implementation, unlike the implementation in other browsers, tries to be as strictly RFC complaint as possible. The issue with the test case you provided above is that the server as usual does the wrong thing. It sends Content-disposition: filename="mcgeesh: testfile" instead of sending Content-disposition: attachment; filename="mcgeesh: testfile" As usual we might have to assume "attachment" when only filename information is supplied to workaround broken servers. See http://greenbytes.de/tech/tc2231/ for an exhastive look into this subject matter complete with testing which we try to ensure Konqueror abides by. We already worked around one issue which the other browsers allowed so I guess we might have to do for this case as well.
Message from the Bugsquad and Konqueror teams: This bug is closed as outdated, as we do not have the manpower to maintain the KDE3 version anymore. If you still can reproduce this issue with Konqueror 4.8.4 or later, please open a new report. Thank you for your understanding.