Confirmed in trunk too. Konqueror is able to download the file, but if kget is set to be the default download manager, he (kget) downloads the file "download.php".

Can someone finally fix this bug? It's quite annoying...
I can't believe the number of things that just work in KDE 3, and don't in KDE 4...

I'll take care of that for the next release unless someone else beats me to it.

Created attachment 34088 [details]
honor the suggested filename from khtml

With this patch, the suggested filename is honored again, as in the version for KDE3.

Some more comments regarding the patch:

The reason for the problem is how the commandline arguments are treated the suggested file name is passed by khtml as the last argument, but not treated as such by kget.

The patch fixes this problem; I'd be happy if you could test it, because it changes the behavior for the commandline arguments (currently, the last argument is treated as the destination directory). I tried hard to keep this behavior with the patch, but I'm wondering if this was actually intended (does anybody actually start kget with some urls and the target directory as last argument?

IMHO, the argument handling as well as the khtml integration should be cleaned up to avoid these ambiguities:

- two urls to download
- one url to download, second url is the suggested file name
- one url to download, second url is the target directory

The patch also changes another thing: instead of blindly accepting the filename and target directory, a file dialog is popped up to let the user
- confirm that she wants to save the file in that directory
- change the filename to one that suits her

kget for KDE3 had an "expert mode" where this confirmation file dialog was skipped, but I for one would like to decide for myself how to name the files and where to put them to.

And last:
kget for KDE3 called 
KIO::Scheduler::checkSlaveOnHold(true);
before creating the transfer/copy jobs in order to make sure to get the same slave that was used by khtml. This was necessary for some download pages, but I'm not sure if it still is. I added them back -- if you deliberately removed them, please tell.

Patch looks good to me. Nice work; thanks!

No change, Kget just downloaded a download.php file while the KDE standard download thingie downloaded the file I wanted correctly.

Hmm, is that a public URL that you tested (i.e. can you post it here)?

Unfortunately no, it needs a registration, and registrations on this website are closed...
If I can find a public website with the same problem, I'll post it here asap.

SVN commit 985473 by pfeiffer:

BUG: 188673
- honor the suggested target filename path (absolute
  or relative) so that downloads started via khtml from
  a page with 
Content-disposition; ... filename="foo"
use that name.

- always pop up a confirmation dialog in that case
- only when khtml already popped up the filedialog,
  kget doesn't do it

- add back the KIO::Scheduler::checkSlaveOnHold() calls
  from KDE3 times, although I'm not sure whether these are still
  necessary


 M  +66 -11    core/kget.cpp  
 M  +5 -3      core/kget.h  
 M  +18 -3     main.cpp  
 M  +2 -0      transfer-plugins/kio/transferKio.cpp  
 M  +2 -0      transfer-plugins/metalink/metalink.cpp  
 M  +1 -1      ui/newtransferdialog.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=985473

SVN commit 985971 by pfeiffer:

forwardport r985473 from 4.2 branch:

BUG: 188673
- honor the suggested target filename path (absolute
  or relative) so that downloads started via khtml from
  a page with
Content-disposition; ... filename="foo"
use that name.

- always pop up a confirmation dialog in that case
- only when khtml already popped up the filedialog,
  kget doesn't do it

- add back the KIO::Scheduler::checkSlaveOnHold() calls
  from KDE3 times, although I'm not sure whether these are still
  necessary


 M  +65 -10    core/kget.cpp  
 M  +5 -3      core/kget.h  
 M  +18 -3     main.cpp  
 M  +2 -0      transfer-plugins/kio/transferKio.cpp  
 M  +2 -0      transfer-plugins/metalink/metalink.cpp  
 M  +1 -1      ui/newtransferdialog.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=985971

Sorry but... I just updated kdenetwork to try that, and it still doesn't work...

SVN commit 986204 by pfeiffer:

BUG: 188673 destDir may actually be not just a directory, but also a file,
so deal with that too.


 M  +12 -1     kget.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=986204

Hmm, then there must be something completely different. Can you please update from svn again, restart kget and the browse with konqueror to http://gis-blog.leonde.de/test.php
kget should ask you to save a file notes-helpful-errormessage.png.
Please check whether you actually get that filename and whether the resulting file is actually a png file.

If that works, then your issue is completely different than the one from this report (does the above bubble bobble url work for you?).

Ok, I've made some tests and found something. If I use Kget as the default Konqueror's download manager, it works. But when I use the option "open with Kget" when clicking a download link, or when I paste the link as a new download, it doesn't work.

Also, this is another problem but when I launch Kget with a finished download in the download list, the download restarts after Kget started.

Ah, that makes sense. Compare with wget, e.g. "wget http://gis-blog.leonde.de/test.php", you will get the correct file (the png), saved as "test.php". You're basically just saving to a file what the webserver sends, without interpreting special http headers, (i.e. content-disposition with the suggested filename).

khtml/konqueror on the other hand do interpret that header and send that information to konqueror *if* you directly click that link or choose "Save link as".

Ok, so if I understand well, this is a normal behavior?! It doesn't matter since I just have to make Kget the default download manager for Konqueror.

Thanks for that ;).

I still have a problem. When I right click on a picture and choose "save picture as..." it triggers Kget (which doesn't happen it KDE 3.x).
Also, when I choose the destination in Konqueror, Kget asks me the destination again, but then, the pictures name is replaced by the first chosen folders name. For exemple, if, in the Konqueror destination window, I choose "Pictures" folder, in Kget window, my picture will be named "Pictures".

Note that it happens with anything I want to download using right click.

I was wrong on one thing. I tested in KDE 3.5 and downloading a picture with right click on a picture and choose "save picture as..." does start Kget. But the destination folder is only asked by Konqueror, and Kget uses the choice made there.

Why not make Kget for KDE 4 behave the same than Kget for KDE 3?

No news? Nobody cares about this?

By the way, I don't know where to post this so... When I tried to download a picture via the KDE download manager wih "Right click", the name field remaned empty.

KDE4 download systems seem to definitely have a problem...

(In reply to comment #18)
> Also, when I choose the destination in Konqueror, Kget asks me the destination
> again, but then, the pictures name is replaced by the first chosen folders
> name. For exemple, if, in the Konqueror destination window, I choose "Pictures"
> folder, in Kget window, my picture will be named "Pictures".
> 
> Note that it happens with anything I want to download using right click.

I think I understand the problem, and I'll try to fix it for KDE 4.3 (I have very little time these days). The solve the problem for real (coding wise) would need creating a real "DownloadManager" interface, that applications can use to add transfers. The current way via commandline arguments is just way too fragile.

SVN commit 999491 by pfeiffer:

BUG: 188673
- this should fix the "Save as" case, where konqueror already asks
  for the target url and passes that to kget.


 M  +11 -6     main.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=999491

Unfortunately the testcase from comment 14 doesn't seem to work for me anymore (unrelated to my changes). Is this my (still 4.2) setup or can anyone confirm that this is broken with 4.3? I do get the correct name, but only a 0-byte file is created.

Ok, so, I made some tests, and we're close to the goal.

When Kget is set as the default download manager, the download works well in the test case from comment #14.

When downloading a picture with "save picture as...", it now works well.

But, still in the test case from comment #14, if I use the option "Open with Kget", Kget asks me for the destination with a different screen, and still uses the chosen folder as the file name.

As for the 0 bytes file, it never happened to me, even the file with the folder's name was, in fact, the good file with a wrong name.

I hope it's clear enough ;).

Ok, hmm, I'll try to explain that cause it's a little wierd.

Here it is: As I said, your test works. I click the link, a great window with folders and files displayed in "list" style asks me where I want to download the file. No problems there.
Second, if I use open with Kget with the test, a little windows displaying only the path, asks me where I want to download the file, but the file name is, in fact, the folder's name.
Now, I tried with a normal link, no php or anything like that. Here is the link: http://www817.megaupload.com/files/c44896fe070b98a4a755a70e13b1a20b/[DB-Z.com]_Dragon_Ball_Kai_13_HD_XVID.avi
I just clicked on the link, which triggered this little window I mentionned earlier, with exactly the same problem.

So, we just need to have the great window for the destinaion choice, everytime. I don't know why there is two different ways to choose the destination, but this one works.

SVN commit 1000860 by pfeiffer:

BUG: 188673
forward port 999491


 M  +7 -2      main.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1000860

SVN commit 1000868 by pfeiffer:

BUG: 188673
so be it, always show the filedialog as it was in KDE 3.x, instead of 
the new-transfer-dialog


 M  +2 -2      main.cpp  
 M  +2 -2      ui/contextmenu.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1000868

SVN commit 1000869 by pfeiffer:

BUG: 188673
forward port from 4.3 branch:
always show the filedialog as it was in KDE 3.x, instead of
the new-transfer-dialog



 M  +2 -2      main.cpp  
 M  +2 -0      ui/contextmenu.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1000869

Cedric, thanks for testing this again and again!

With the latest changes, the filedialog should always be used when kget is invoked from konqueror/khtml or via "Open with KGet".

Everything seems ok now. I'll let you know if I have any other problem of this type.
Thanks ;).

*** Bug 201308 has been marked as a duplicate of this bug. ***

*** Bug 202048 has been marked as a duplicate of this bug. ***

This bug seems to be back... Kget doesn't get the filename from the server when the main KDE download utility does...