Bug 213078

Summary:	cannot download file when the link point to it inderectly
Product:	[Applications] kget	Reporter:	Kamil Neczaj <kneczaj>
Component:	general	Assignee:	KGet authors <kget>
Status:	CONFIRMED ---
Severity:	normal	CC:	aiacovitti, dev+kde, d_baron, justin.zobel, kollix, reuben_p
Priority:	NOR	Keywords:	triaged
Version:	20.08
Target Milestone:	---
Platform:	unspecified
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Kamil Neczaj 2009-11-04 13:14:11 UTC

Version:            (using KDE 4.3.2)
OS:                Linux
Installed from:    Unlisted Binary Package

When the link points to php?id=somenumber for example http://www.moodle.cel.agh.edu.pl/weaiie/mod/resource/view.php?id=7507 (sory this doesn't open because it require logging in) I cannot download the pdf file the link piont to (unfortunatelly indirectly) by using right click->save as nor right click->download with kget. Konqueror only tries to save the php file. In firefox saving such a pdf using such an indirect link works well.

I will add another example file when I find some.

Comment 1 Frank Steinmetzger 2010-11-04 16:16:33 UTC

I confirm this on 4.4.5, Debian Testing.

I implemented such a function on a website on which users can upload different types of files. To avoid file name collisions on the server, the files are named after their database ID and are downloaded via download.php?id=<database ID>, the PHP file then delivers the file itself.

Other browsers I tested did this right (Firefox, Chromium and even IE6); they fetch the filename first which is provided by download.php in the HTTP header »Content-Disposition: inline; filename="..."«. Then they can suggest that filename in the Save As dialogue.

Comment 2 Martin Koller 2011-06-23 18:15:25 UTC

Can you give an URL to directly test this problem ?

Comment 3 Reuben 2012-04-16 14:37:55 UTC

http://www.fpdf.org/fr/dl.php?id=22 (zip archive)
Konqeror seems to be fine, however KGet doesn't follow the content disposition filename, when it's added either directly or context menu,

Comment 4 Andrea Iacovitti 2012-04-18 12:57:25 UTC

(In reply to comment #3)
> http://www.fpdf.org/fr/dl.php?id=22 (zip archive)
> Konqeror seems to be fine, however KGet doesn't follow the content
> disposition filename, when it's added either directly or context menu,

It seems this bug must be reassigned to kget, doing it.

Comment 5 Myriam Schweingruber 2012-06-21 19:59:45 UTC

Which exact kget version is this reproducible with?

Comment 6 Andrea Iacovitti 2012-06-21 20:34:43 UTC

(In reply to comment #5)
> Which exact kget version is this reproducible with?
at least 2.8.4

Comment 7 Andrew Crouthamel 2018-09-23 02:38:54 UTC

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

Comment 8 Reuben 2018-10-16 01:29:54 UTC

Still occurring using the link in comment #3.

Comment 9 Chris 2020-08-20 18:55:44 UTC

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

Comment 10 Justin Zobel 2020-11-24 02:49:37 UTC

Confirmed it is not following the redirect as a browser would (tested in Firefox, it redirects correctly).