Bug 295717

Summary:	kget uses wrong download file name in case download link has redirection
Product:	[Applications] kget	Reporter:	squan
Component:	general	Assignee:	KGet bugs <kget-bugs-null>
Status:	RESOLVED DUPLICATE
Severity:	normal	CC:	kevin.clevenger
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	unspecified
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description squan 2012-03-10 20:42:43 UTC

User-Agent:       Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.34 (KHTML, like Gecko) rekonq Safari/534.34
Build Identifier: 

If you click a link in yout browser, the link target will be loaded in kget.
Now with KDE-4.8.1 this has two regresssions:
1) when the link target has redirections, the target file name is no longer correct, as described in bug 181771 aka bug 180136 (which was fixed and working properly for sevaral iteratiions of KDE until 4.8.0).
2) when clicking a link in rekonq the download starts right away without kget showing a dialog for selecting the download destination (while when initiated with konqueror a file dialog will be shown).


Reproducible: Always

Comment 1 Kevin Clevenger 2012-08-01 17:49:09 UTC

I can confirm this behaviour using kget or not. It's particularly troublesome downloading attachments from salesforce.com. In my case the actual attached file is http://other.server.org/attachments/<long UUID>. When using other browsers the redirect from force.com to other.server.org works correctly and the file is renamed from <long UUID> to <something_sensible.txt> before the Save As diaglog is opened.

Comment 2 Kevin Clevenger 2012-08-19 20:46:10 UTC

Here's an example: https://www.box.com/s/5ba7b71e7a3e23a411e5 which should download as mongolato.tar.xz and acutally downloads as <random string>.

Comment 3 Lukas Appelhans 2012-08-21 08:53:42 UTC

For 2) check your rekonq configuration, "Always ask where to save downloads" or something like that, on the first page.

For one, I'm marking this as a duplicate to 180136, which is indeed not (yet) fixed, but will be in a few minutes.

Lukas

*** This bug has been marked as a duplicate of bug 180136 ***