Welcome Guest, Not a member yet? Register   Sign In
force_download trys to open pdf in browser
#1

[eluser]Unknown[/eluser]
hey,

i'm trying to download a pdf-file using the "force_download"-method but it trys to show the file on the page and doesn't download it.

my code for the download function is:

Code:
public function download($filename) {

$this->load->helper('download');
$path= './assets/mypath/'. $filename;

$data = file_get_contents($path);
force_download($filename, $data);
    }

what am i doing wrong?
#2

[eluser]PhilTem[/eluser]
I know that problem. Just had a glance at the CI code of the force_download-download. The problem is - I think - from one of the headers set within that function.
Made a little googleing and found a forum's topic.

Try to do it manually with accordingly with
Code:
header("Content-Type: application/force-download");
header("Content-Disposition: inline; filename=\"" . $name_mb . "\""); // set the filename here
header("Content-length: " . (string) (filesize($path_mb)));
header("Expires: ".gmdate("D, d M Y H:i:s", mktime(date("H")+2, date("i"), date("s"), date("m"), date("d"), date("Y")))." GMT");
header("Last-Modified: ".gmdate("D, d M Y H:i:s")." GMT");
header("Cache-Control: no-cache, must-revalidate");
header("Pragma: no-cache");

because force_download() uses
Code:
header('Content-Type: "'.$mime.'"');

which is interpreted from some browsers with built-in Adobe Reader as a pdf file to read inside the browser which ignores the force-download ability.

Tell me if it worked and is reproducible. If so, maybe file an issue on @EllisLab's git-page.
#3

[eluser]Kamarg[/eluser]
You shouldn't worry about it. This is generally a user preference set in the browser. Let the user open the file however they choose to open it not how you think they should.
#4

[eluser]Narf[/eluser]
[quote author="Kamarg" date="1330439667"]You shouldn't worry about it. This is generally a user preference set in the browser. Let the user open the file however they choose to open it not how you think they should.[/quote]

Actually, it's not - if there's a plugin that can handle the specified content type, the browser (in most cases at least) will not ask you what you want to do with it. The Open with/Save dialog screen appears if the browser cannot handle the content by itself and usually suggests a program to open it with based on the file extension.
#5

[eluser]Narf[/eluser]
@staccato_mamba, can you confirm if the following resolves your problem?

https://github.com/EllisLab/CodeIgniter/pull/1092
#6

[eluser]Kamarg[/eluser]
[quote author="Narf" date="1330514821"][quote author="Kamarg" date="1330439667"]You shouldn't worry about it. This is generally a user preference set in the browser. Let the user open the file however they choose to open it not how you think they should.[/quote]

Actually, it's not - if there's a plugin that can handle the specified content type, the browser (in most cases at least) will not ask you what you want to do with it. The Open with/Save dialog screen appears if the browser cannot handle the content by itself and usually suggests a program to open it with based on the file extension.[/quote]

You're saying that installing a plugin for a browser is not a user preference? I'd be awfully annoyed if I put in the effort to make pdfs open in my browser and a website forced me to open it outside the browser.
#7

[eluser]CroNiX[/eluser]
If it opens in the browser they just have to hit the save icon. More than likely the user will know this.
#8

[eluser]Narf[/eluser]
[quote author="Kamarg" date="1330524693"][quote author="Narf" date="1330514821"][quote author="Kamarg" date="1330439667"]You shouldn't worry about it. This is generally a user preference set in the browser. Let the user open the file however they choose to open it not how you think they should.[/quote]

Actually, it's not - if there's a plugin that can handle the specified content type, the browser (in most cases at least) will not ask you what you want to do with it. The Open with/Save dialog screen appears if the browser cannot handle the content by itself and usually suggests a program to open it with based on the file extension.[/quote]

You're saying that installing a plugin for a browser is not a user preference? I'd be awfully annoyed if I put in the effort to make pdfs open in my browser and a website forced me to open it outside the browser.[/quote]

Well, if you're in e.g. a corporate environment, where you don't have control over what's installed on your workstation - it's not a user preference. But that's not the point - that function is not named force_download() for no reason and to be honest - I personally would be pretty annoyed if I click a download link and content is displayed in the browser itself instead.
#9

[eluser]CroNiX[/eluser]
I think it would be a bad idea to circumvent the expected behavior of the end user. If their browser is set up to view pdfs inline, that should be how it works for them, imho, because that is the behavior they expect.

But, I believe the only way to force a download even if they have a pdf reader installed in their browser is to send that pdf as mime type application/octet-stream instead of application/pdf.
#10

[eluser]CroNiX[/eluser]
An easy solution would be to add an optional 3rd parameter to force_download() allowing you to select the mime type the file will be downloaded as instead of its native mime type.

Edit: which is exactly what narf's pull request does. Nice!




Theme © iAndrew 2016 - Forum software by © MyBB