Bug 198809 - kget cannot determine file name for redirecting URLs
Summary: kget cannot determine file name for redirecting URLs
Status: RESOLVED FIXED
Alias: None
Product: kget
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: KGet authors
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-03 17:51 UTC by Andrey Borzenkov
Modified: 2009-07-04 21:28 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrey Borzenkov 2009-07-03 17:51:36 UTC
Version:            (using Devel)
OS:                Linux
Installed from:    Compiled sources

KDE 4.2.95

Today large number of download links point to some dynamic CGI handler like .../download?id=1234. When I use Save As in Konqueror it correctly resolves final name and offers it as target file name. But KGet stops at the initial URL, which means I get dozens of files with name "download"; what is worse, it suggests to overwrite file with the same name :(

This is one of the most annoying mis-features of KGet and is quite old, since KDE 3.5 at least.

I understand that it could sound as wish request. But IMHO this is basic feature of any download manager. Also it makes it largely impossible to use KGet as default download manager for Konqueror as it mangles downloaded names.

It would be really very nice if it could be finally fixed. Konqueror can resolve names, so it should be doable for KGet as well.
Comment 1 Carsten Pfeiffer 2009-07-04 00:03:20 UTC
Can you please post a URL that we can use for testing? Also, I think that this is already fixed in current SVN, but maybe there's another case that we missed.
Comment 2 Andrey Borzenkov 2009-07-04 17:03:14 UTC
Sure.

http://download.mozilla.org/?product=firefox-3.5&os=linux&lang=ru :)
Comment 3 Carsten Pfeiffer 2009-07-04 21:28:18 UTC
Thanks, in that case the bug is indeed already fixed. (With #188673)