Learn how to build an E-Commerce site with Angular 5, a JavaScript framework used by developers to build web, desktop, and mobile applications.
Force PDF to open inline as opposed to dowload
I am using a module in CMSMS called "Uploads". It allows the site owner to echo lists of PDF files on a web page.
Problem is that when clicking to open a PDF (even using target_blank) the PDF firsts downloads before opening.
Is there anyway to use htacess to force the PDF in the browser window?
It looks like there may be php code in the Uploads module that is modifying the headers and forcing PDFs to download.
Thanks in advance.
N
Problem is that when clicking to open a PDF (even using target_blank) the PDF firsts downloads before opening.
Is there anyway to use htacess to force the PDF in the browser window?
It looks like there may be php code in the Uploads module that is modifying the headers and forcing PDFs to download.
Thanks in advance.
N
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
you can try this
<IfModule mod_headers.c>
<FilesMatch "\.pdf$">
Header set Content-Disposition "attachment"
</FilesMatch>
</IfModule>
but if php toys with the headers as well i'm unsure which will win...
on apache 2.4 there may be a forcexxx directive that will override php's headers entirely ( the equivalent exists for filenames and mime types so disposition probably can be forced as well ) but i don't know which one without googling. anyway i'd try the above first.
<IfModule mod_headers.c>
<FilesMatch "\.pdf$">
Header set Content-Disposition "attachment"
</FilesMatch>
</IfModule>
but if php toys with the headers as well i'm unsure which will win...
on apache 2.4 there may be a forcexxx directive that will override php's headers entirely ( the equivalent exists for filenames and mime types so disposition probably can be forced as well ) but i don't know which one without googling. anyway i'd try the above first.
did you actually check what headers were sent ? or it just did not work and you're assuming php won ?
you probably should check with something like debug tools in your browser or a sniffer
you probably should check with something like debug tools in your browser or a sniffer
I'll see if I can find the headers in the morning. FYI and if it helps but you can access the downloads in question from the fly out right side menu here http://server.beaconhilldesign.co.nz/~kevinmcdonald/
you do get attachment header :
either the apache hack does not work at all ( which can be checked by adding a different dummy header ) or php actually does set the headers and "wins"
given the url, my guess is the file is handled directly by apache so there is something wrong in your htaccess or it might not be parsed at all
to see if the htaccess works, stick in a "dummy" line and you should get a 550 error
but first try this
... since there is a trailing '/' in the links ( i added a '/' at the end of the filematch )
... and changed the header to "inline" ( made another mistake on my previous post, sorry )
HTTP/1.1 200 OK
Date: Tue, 14 Mar 2017 09:14:07 GMT
Server: Apache
X-Powered-By: PHP/5.6.21
Pragma: public
Expires: 0
Cache-Control: must-revalidate, post-check=0, pre-check=0, private
Content-Description: File Transfer
[b]Content-Disposition: attachment; filename="Methamphetamine_Contam.pdf"
[/b]Content-Transfer-Encoding: binary
Content-Length: 268923
Connection: close
Content-Type: application/octet-stream
either the apache hack does not work at all ( which can be checked by adding a different dummy header ) or php actually does set the headers and "wins"
given the url, my guess is the file is handled directly by apache so there is something wrong in your htaccess or it might not be parsed at all
to see if the htaccess works, stick in a "dummy" line and you should get a 550 error
but first try this
<IfModule mod_headers.c>
<FilesMatch "\.pdf/$">
Header set Content-Disposition "inline"
</FilesMatch>
</IfModule>
... since there is a trailing '/' in the links ( i added a '/' at the end of the filematch )
... and changed the header to "inline" ( made another mistake on my previous post, sorry )
Cool, I'll make the update in the morning when I have access to the back end. You might be interested but I made a test link earlier tonight further down the page ( just under "were the real deal" text ) but on this occasion I created the link manually as opposed to via the CMS uploads module. The link opens the PDF fine in the browser.
You may be swimming upstream against the way client devices and browsers work. In my experience, browsers treat PDF files like image files. The browser downloads the entire file and then decides what to do with it. If the file is small and the internet connection is fast, this is more or less transparent to the human client who is watching the browser screen. It the file is large, the download may be an obvious feature. If the client browser has settings to download, but not display, images may be downloaded but not displayed. I expect the same is true for PDF files. With the browser default settings, the choice to display a PDF or not display a PDF rests with the client at the time of download. This makes sense in an increasingly mobile world, where your users may not want to deal with a multi-page legal document on an iPhone!
In any case, it will be easier to get to acceptable behavior if you've got valid markup. There are some things you might want to address (the W3 validator is a very helpful tool):
https://validator.w3.org/nu/?doc=http%3A%2F%2Fbeaconhilldesign.co.nz%2F~kevinmcdonald%2F
Generally speaking, a trailing slash does not belong on a URL that points to a file. A trailing slash usually indicates a directory path.
Here is a little script I made (the SSCCE) to examine the issue. Variables include the source directory for the PDF, whether there is a trailing slash, whether the document opens in a new window or inline, whether the link is relative or explicit. Check the source below to see how these are combined in the five tests.
24 Fully Qualified Link, Trailing slash, Opens _blank
Firefox: Dialog box asking to open or save
Chrome: Downloaded the PDF, put link at bottom of browser viewport
24 Fully Qualified Link, NO Trailing slash, Opens inLine (something is wrong with this PDF)
Firefox: 500 Internal Server Error
Chrome: 500 Internal Server Error
files Fully Qualified Link, NO Trailing slash, Opens inLine
Firefox: Dialog box asking to open or save
Chrome: Downloaded the PDF, put link at bottom of browser viewport
files Relative Link, NO Trailing slash, Opens _blank
Firefox: Dialog box asking to open or save
Chrome: Downloaded the PDF, put link at bottom of browser viewport
files Relative Link, NO Trailing slash, Opens inLine
Firefox: Dialog box asking to open or save
Chrome: Downloaded the PDF, put link at bottom of browser viewport
When I told FF to "save," it downloaded the PDF but did not switch to a viewer. When I told FF to "open" with Adobe Reader or similar, it downloaded the PDF and started the viewer in a new window (not a new tab). When the target="_blank" was used, FF started a new tab with about:blank but put nothing into the tab -- a useless action; this seemed to be independent of opening the reader. You might not want target="_blank" when you're using PDF documents with Firefox.
With Chrome, in all cases, the behavior was the same. The target="_blank" made no difference. Any time I clicked the link at the bottom of the viewport, Chrome opened the PDF in a new tab of the same window.
Life's too short for me to test with IE, but you can do that.
As you go about your tests, be aware that your browser settings and cache may vary from one test to the next. You might want to clear the cache, delete all copies of the downloaded document, erase cookies, etc., between tests, so you're testing in a steady state and not in a state that is partially dependent on prior tests. Private or Incognito is often useful to avoid noise from prior tests.
Here's the link on my server:
https://iconoun.com/demo/temp_neil_bradley.php
Here's the script:
In any case, it will be easier to get to acceptable behavior if you've got valid markup. There are some things you might want to address (the W3 validator is a very helpful tool):
https://validator.w3.org/nu/?doc=http%3A%2F%2Fbeaconhilldesign.co.nz%2F~kevinmcdonald%2F
Generally speaking, a trailing slash does not belong on a URL that points to a file. A trailing slash usually indicates a directory path.
Here is a little script I made (the SSCCE) to examine the issue. Variables include the source directory for the PDF, whether there is a trailing slash, whether the document opens in a new window or inline, whether the link is relative or explicit. Check the source below to see how these are combined in the five tests.
24 Fully Qualified Link, Trailing slash, Opens _blank
Firefox: Dialog box asking to open or save
Chrome: Downloaded the PDF, put link at bottom of browser viewport
24 Fully Qualified Link, NO Trailing slash, Opens inLine (something is wrong with this PDF)
Firefox: 500 Internal Server Error
Chrome: 500 Internal Server Error
files Fully Qualified Link, NO Trailing slash, Opens inLine
Firefox: Dialog box asking to open or save
Chrome: Downloaded the PDF, put link at bottom of browser viewport
files Relative Link, NO Trailing slash, Opens _blank
Firefox: Dialog box asking to open or save
Chrome: Downloaded the PDF, put link at bottom of browser viewport
files Relative Link, NO Trailing slash, Opens inLine
Firefox: Dialog box asking to open or save
Chrome: Downloaded the PDF, put link at bottom of browser viewport
When I told FF to "save," it downloaded the PDF but did not switch to a viewer. When I told FF to "open" with Adobe Reader or similar, it downloaded the PDF and started the viewer in a new window (not a new tab). When the target="_blank" was used, FF started a new tab with about:blank but put nothing into the tab -- a useless action; this seemed to be independent of opening the reader. You might not want target="_blank" when you're using PDF documents with Firefox.
With Chrome, in all cases, the behavior was the same. The target="_blank" made no difference. Any time I clicked the link at the bottom of the viewport, Chrome opened the PDF in a new tab of the same window.
Life's too short for me to test with IE, but you can do that.
As you go about your tests, be aware that your browser settings and cache may vary from one test to the next. You might want to clear the cache, delete all copies of the downloaded document, erase cookies, etc., between tests, so you're testing in a steady state and not in a state that is partially dependent on prior tests. Private or Incognito is often useful to avoid noise from prior tests.
Here's the link on my server:
https://iconoun.com/demo/temp_neil_bradley.php
Here's the script:
<?php // demo/temp_neil_bradley.php
/**
* https://www.experts-exchange.com/questions/29008867/Force-PDF-to-open-inline-as-opposed-to-dowload.html
*/
error_reporting(E_ALL);
$html = <<<EOD
<!DOCTYPE html>
<html>
<head>
<base href="http://beaconhilldesign.co.nz/~kevinmcdonald/" />
</head>
<body>
<p>
<a target="_blank" href="http://beaconhilldesign.co.nz/~kevinmcdonald/uploads/24/Buying_a_Houes.pdf/">24 Fully Qualified Link, Trailing slash, Opens _blank</a><br>
<a href="http://beaconhilldesign.co.nz/~kevinmcdonald/uploads/24/Buying_a_Houes.pdf">24 Fully Qualified Link, NO Trailing slash, Opens inLine</a><br>
<a href="http://beaconhilldesign.co.nz/~kevinmcdonald/uploads/files/Buy_%26_Sell_Property_-_IRD.pdf">files Fully Qualified Link, NO Trailing slash, Opens inLine</a><br>
<a target="_blank" href="uploads/files/Buy_%26_Sell_Property_-_IRD.pdf">files Relative Link, NO Trailing slash, Opens _blank</a><br>
<a href="uploads/files/Buy_%26_Sell_Property_-_IRD.pdf">files Relative Link, NO Trailing slash, Opens inLine</a><br>
</p>
</body>
</html>
EOD;
echo $html;
Hi all,
I added the code to the htacess as per your suggestion Skullnobrains but still the same result.
Ray, as always thanks you for your excellent input.
The issue we are experiencing however is not linked to individual browser types but a header that is somehow set in the module we have used to enable the client to upload lists of their own docs.
To illustrate the issue more effectively I have added a test link to the top of the docs list in the fly out right hand column. The first link (labelled "test") was manually entered by myself and performs as expected. I.E. The PDF opens in the browser window.
All subsequent PDF files however behave quite differently due to what we believe is a header set in the Uploads Module that is forcing them to behave in a certain way.
Hope this clarifies.
I added the code to the htacess as per your suggestion Skullnobrains but still the same result.
Ray, as always thanks you for your excellent input.
The issue we are experiencing however is not linked to individual browser types but a header that is somehow set in the module we have used to enable the client to upload lists of their own docs.
To illustrate the issue more effectively I have added a test link to the top of the docs list in the fly out right hand column. The first link (labelled "test") was manually entered by myself and performs as expected. I.E. The PDF opens in the browser window.
All subsequent PDF files however behave quite differently due to what we believe is a header set in the Uploads Module that is forcing them to behave in a certain way.
Hope this clarifies.
This link behaves the same way as the others I noted above. Please find the Firefox screen shot attached. I cannot think of anything about a "header somehow set in the ... upload lists" that could be in play here. The upload, once complete, should be a "finished task" and any headers that are associated with downloading the files would be prepared and presented at the time of the download. In other words, I don't think we're close to the "real issue" yet.
Browsers will reliably display pdfs inline providing the proper headers are set and a pdf plugin is installed on the client machine. They will failover to download if you dont have the plugin
I cannot test headers ( mobile phone and poor connectivity ) but either of you should bd able to.
I d first try to add an entirely different header just to see if the htaccess works. They might be disabled in the config entirely.
There is no workaround other than toying and modifying headers on the fly with a proxy. Either this can be handled in apache which is likely or you ll need to modify the php code.
I cannot test headers ( mobile phone and poor connectivity ) but either of you should bd able to.
I d first try to add an entirely different header just to see if the htaccess works. They might be disabled in the config entirely.
There is no workaround other than toying and modifying headers on the fly with a proxy. Either this can be handled in apache which is likely or you ll need to modify the php code.
and a pdf plugin is installedImportant note! If you're going to require your clients to have a PDF plugin, you might want to tell them of the requirement. Or just don't worry about it because the file is getting sent correctly. In other words, you're already following the best practices, and any changes to the overall process need to be made on the client's end of things.
FWIW, when I have produced PDF documents in web applications, I've stored the documents on the server, and given the client a clickable link -- exactly what you're doing here. I have never had a complaint about accessibility of the PDFs, so I'm thinking most clients have their own setup for PDFs and they are happy with the outcome. A long time ago, I once tried to send an email with a PDF as an attachment, and quickly got a chorus of "no, no, no," because clients on mobile devices were getting the email headers and bodies, but their mail servers were stripping the attachments. So I just sent the links in the email, or exposed the links in the body of the HTML document, and everyone was happy!
The website uses CMSMS as its CMS platform. I contacted CMSMS via their forum yesterday and submitted a question relating to the "Uploads Module". They have confirmed that this module is explicitly forcing a download (by http headers), hence the behaviours of the PDF's.
They have suggested a fix that involves an update to the module itself.
As an experiment yesterday I added the html 5 tag "download" to the PDF links and while this did not solve my issue it did effect the behaviour of the download to the point where the client is happy to sign off the site.
Reviewing this question now in an attempt to assign points in the fairest manner possible.
They have suggested a fix that involves an update to the module itself.
As an experiment yesterday I added the html 5 tag "download" to the PDF links and while this did not solve my issue it did effect the behaviour of the download to the point where the client is happy to sign off the site.
Reviewing this question now in an attempt to assign points in the fairest manner possible.
My recommendation: Give all the points to this.
https://www.experts-exchange.com/questions/29008867/Force-PDF-to-open-inline-as-opposed-to-dowload.html#a42047422
https://www.experts-exchange.com/questions/29008867/Force-PDF-to-open-inline-as-opposed-to-dowload.html#a42047422
Thanks for your patience with this question skullnobrains.
The module in question has been successfully updated thanks to your guidance.
Best.
Neil
The module in question has been successfully updated thanks to your guidance.
Best.
Neil
you're giving me too much credit ( both of you ), but thanks and good to know things do work out as the CMS guys are reactive.
btw, we did not discuss which header should/not be provided by the CMS
playing by the book, you probably should use the accept header and use inline or attachment depending on the mime type. but any regular browser is fully able to do the same ( and they most often use */* for the accept header anyway )
i'd recommend letting the web server handle downloads if feasible or at least try and use regular urls : the inline header does not provide a file name but browsers will usually guess reasonably ( use the basename of the url ). not providing the header at all will usually and more reliably produce the desired results. most browsers will default to display pdfs inline as long as there is an appropriate plugin and the user did not specify he wanted a different behavior. using regular browser links also allows the user to right click and download the target without hassle if he wants to.
... so not specifying anything is actually the best bet i think.
best regards
btw, we did not discuss which header should/not be provided by the CMS
playing by the book, you probably should use the accept header and use inline or attachment depending on the mime type. but any regular browser is fully able to do the same ( and they most often use */* for the accept header anyway )
i'd recommend letting the web server handle downloads if feasible or at least try and use regular urls : the inline header does not provide a file name but browsers will usually guess reasonably ( use the basename of the url ). not providing the header at all will usually and more reliably produce the desired results. most browsers will default to display pdfs inline as long as there is an appropriate plugin and the user did not specify he wanted a different behavior. using regular browser links also allows the user to right click and download the target without hassle if he wants to.
... so not specifying anything is actually the best bet i think.
best regards
Premium Content
You need an Expert Office subscription to comment.Start Free Trial