So, I have a file that sends the following:
header("Pragma: public");
header("Expires: 0");
header("Cache-Control: private");
header("Content-type: application/pdf");
header("Content-disposition: inline; filename=file.pdf");
header("Content-length: 7735");
then I echo out the file - it is a PDF file.
Works fine in IE6 & 7 on XP (and FF for that matter)
The very same code shows nothing when running on IE8 on either XP or Vista.
There are no security warnings, etc so I don't think it has to do with that.
And, if my memory serves me correctly, this worked on IE8 a while ago.
What am I doing wrong here? Am I missing something out of the headers?
Is there a way for me to see what header information normal comes over when viewing a PDF in IE8 so I know what to emulate?
After looking at things it still works in IE8 EXCEPT when SSL is on
Under HTTPS and IE8, those headers fix the download problem:
header("Cache-Control: must-revalidate, post-check=0, pre-check=0");
header("Pragma: public");
Other X-something headers did not make any difference.
It has probably to do do with the SSL. I read this article (in German, with code examples) where the author set the following header:
header('Pragma: anytextexeptno-cache', true);
I'm not sure what is needed, but here is what you could do.
Put the file temporarily in a public place on your server, make syre you can download that with a direct link in IE8, Use firefox LiveHTTP headers or similar to grab all headers that the server sends. Spit them out in exactly the same way and order in your script. (And don't forget to delete the file).
Something I want to add, as I faced this problem, too, in a slightly different way using Joomla.
Normal PDF-Output of content worked fine, in all browsers.
But the generation of a pdf from within my own component (using JDocument, tho) generated the bevahiour mentioned above.
My solution: Explicitly enable caching for my component using the following statement in view.html.php:
JResponse::allowCache(true);
Maybe that helps somebody.
I'm using HTTPS and i had some problems, but using those headers the download did.
Try it.
header("Cache-Control: must-revalidate, post-check=0, pre-check=0");
header("Pragma: public");
header("X-Download-Options: noopen "); // For IE8
header("X-Content-Type-Options: nosniff"); // For IE8
header("Content-type: application/pdf");
header("Content-disposition: inline; filename=file.pdf");
header("Content-length: 7735");
The problem is you cant direct open. Just save.
Possibly related: Can't display PDF from HTTPS in IE 8 (on 64-bit Vista)
Related
I'm having this issue that I can't solve for the life of me.
I have a simple php script that redirects to pdfs, the code is as follows:
$file = "url/to/file";
header("Pragma: public");
header("Expires: 0");
header("Cache-Control: must-revalidate, post-check=0, pre-check=0");
header("Cache-Control: private", false);
header("Content-Description: File Transfer");
header('Content-type: application/pdf');
header('Content-Disposition: inline; filename="somefile.pdf"');
header('Content-Transfer-Encoding: binary');
readfile($file);
exit();
If I try it directly in a browser tab, it works, it connects with Chrome's pdf plugin and shows it to me. If I try to put this on a link on another page, or try to open it via window.open in javascript, It shows a blank page. This only happens in Chrome and Safari, Firefox and Edge show it fine. Before anyone asks, I've tried it with and without the cache and content-description headers, which I've got from answers I found here, this is just the last version I have.
Any ideas?
Thanks in advance
EDIT
I forgot to mention that the problem persists on the blank tab even if I reload the page. I've checked the Network tab on devtools, they show identical results for bot requests and responses (the redirect and the direct one) but the redirect doesn't work. Also, no errors of any kind on either one.
Also, I've tried it without the exit(), doesn't change a thing.
As mentioned in the comments by ylva, for anyone searching for this, the answer can be found here
Open PDF from Chrome IFRAME failed with default PDF viewer
Main thing is, Chrome's PDF viewer embeds the PDF as an application, so if the link to a PDF file comes from an iframe, and this iframe has the sandbox attribute, chrome won't let it run, you either have to remove the sandbox attribute or have to install your own PDF viewer. So it had nothing to do with the PHP code itself.
Cheers
I have reports generated in PHP / FPDF / FPDF2File that are usually displayed in the browser window.
Notice:
The parameters are passed to the PHP that generates report POST.
The file is being accessed exclusively via HTTPS with a valid certificate.
The web server is able to log all errors and errors are being properly recorded in the log, but no error related to that FPDF/PHP is being recorded. (Ie I clean the error log, run the report and no error appears in the log ... forcing a mistake on purpose and it is registered). Thus, it seems that there is no syntax error.
The Content-type used is: header ( 'Content-type: application / pdf');
The problem occurs in Windows computers with Google Chrome (tested on multiple machines).
All buttons of the PDF rendering plug-in browsers (save, print, rotate, zoom, etc.) work normally. Except the save button in Google Chrome (in other browsers work normal).
When trying to save the PDF already opened and displayed on Google Chrome, the following error occurs:
Failure - Network error
Therefore, you can not save the PDF, unless you go to print and print in PDF, or print the PDF PDF, which does not make much sense.
Could someone tell how to solve this error?
Thanks a lot!
Do you set the no-store property of the Cache-Control header?
I don't know why, but for me it worked after changing
header("Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0");
to
header("Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0");
#Amryn's answer actually worked for me. Here's my full header setup:
header('Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0');
header('Content-type: application/pdf');
header('Content-Disposition: inline; filename="relatorio-clientes.pdf"');
header('Content-Transfer-Encoding: binary');
header('Content-Length: ' . strlen(ltrim($content)));
header('Accept-Ranges: ' . strlen(ltrim($content)));
echo $content;
If you use the Print option and Save as PDF, network error does not occur (workaround).
That's works for me :
Remove all characters like space after the php close tag ?>
Found here :
https://stackoverflow.com/a/13463631/2267379
Simple solution: Don't do a
return $pdf->Output('medienpass.pdf', 'D');
in your getPdf() function because the output will be wrapped up in a
lot of html code.
Instead return only your pdf to the client:
die($pdf->Output('medienpass.pdf', 'D'));
I was searching already for a long time and I havent seen any right answer yet.
I'm trying to create a system in PHP where the user can download a signPicture that I create in JPG.
The program is working fine in all desktop computers. There is not problem at all, even for IE8.
The header that I use:
header("Content-Type: application/octet-stream");
header('Content-Disposition: attachment; filename="test.jpg"');
in the end i just stream the picture:
imagejpeg($imgSign,NULL,100);
How I said, it's working really good in every browser. But then we get to the mobile devices, where in android for example, download a test.jpg file... but then it cannot open... and the same with ipad (actually doesnt download, it show the image in the browser and than I save it... but it does not open either).
I also try more examples that I saw, but doesnt change anything, like:
header("Pragma: public");
header("Expires: 0");
header("Cache-Control: must-revalidate, post-check=0, pre-check=0");
header("Content-Type: application/force-download");
header("Content-Type: application/download");
header("Content-Transfer-Encoding: binary ");
Any idea how to sort this out in mobile devices?
Thanks!
I got it!
There were differents problems. I found the clear solution in comments from this post:
http://www.digiblog.de/2011/04/android-and-the-download-file-headers/
header("Content-Type: application/octet-stream");
header('Content-Disposition: attachment; filename="test.JPG"');
The important steps: I send everything with a form. The form, to make it work in mobiles, needs to have the target='_top' and the method='get'
It also make errors if the extention (jpg) is not in UPPERCASE and the file name is not between " ".
Now it works in all devices that I try by far. :)
Special thanks to Jörg Wagner, author of the post.
I am using Zend and have some files outside of the webroot that I would like to be able to serve up. I have tried two approaches, both of which work in all browsers except for versions of IE 8 or lower.
The two (working) approaches that I have tried are the following:
// Approach #1
header('Content-Type: application/pdf');
header("Pragma: ");
header("Content-Disposition: attachment; filename=\"$filename\"");
//header('Content-Transfer-Encoding: binary');
header("Pragma: no-cache");
header("Expires: 0");
readfile($file);
// Approach #2
$this->getResponse()
->setHeader('Content-Disposition', "attachment; filename=$filename")
->setHeader('Content-type', 'application/x-pdf');
fpassthru($file);
Like I said, both approaches work in modern browsers (even IE9) but not in older versions of IE. The error I am getting is the following: http://cl.ly/image/1G3x370b1s09
I have looked into several posts on this topic and tried more different combinations of headers than I can even count. Is there a more bulletproof way of handling this functionality that wont cause issues with older browsers?
Thanks!
I've fought with this before and I think it stems from caching headers.
There's three: Expires, Cache-Control (HTTP 1.1), and Pragma (HTTP 1.0). My experience has been the older versions of IE like to see all three of these headers. Try using the following prior to any other headers and content you send:
header("Cache-control: no-cache");
header("Pragma: no-cache");
header("Expires: -1");
This article from Microsoft goes in to more discussion about the caching headers.
This is what I have done in the past to get it to work:
$file = $fileInfo->openFile('r');
header("Pragma: public");
header("Cache-Control: public");
header('Content-type: application/pdf');
header('Content-Disposition: attachment; filename="'.$file->getFilename().'"');
print $file->fpassthru()
Against my will I gave up on trying to fight with headers and completely changed the way I am handling file downloads. When a user requests a file now, it is temporarily hashed, copied to an area that the web-server can see, the user is redirect to that file and once they leave the download area the file is deleted. If they go inactive the file is deleted automatically at a set interval.
Thank you for all of the input kulishch and how ironic is it that you are from Minnesota as well!? Happy Holidays!
-- Nicholas
Follwing the advice at http://support.microsoft.com/default.aspx?scid=KB;EN-US;q316431&, these headers worked for me:
header("Cache-control: max-age=3600, must-revalidate");
header("Pragma: public");
header("Expires: -1");
I always get caught out by this! :(
I'm trying to force download a image file (jpg for example) using php. So I have a script here force.php and here would be the code:
header("Pragma: public"); // required
header("Expires: 0");
header("Cache-Control: must-revalidate, post-check=0, pre-check=0");
header("Cache-Control: private",false); // required for certain browsers
header('Content-Description: File Transfer');
header("Content-Type: image/jpeg");
header('Content-Length: ' . filesize($file));
header('Content-Disposition: attachment; filename=test.jpg');
readfile($file);
Now the problem is for some browsers (mobile phone browsers especially), it'll work properly and prompt test.jpg for the user to save. However on some browser, it'll prompt force.php as download. Any solution?
Thank you!
Content disposition header highly depends on how a particular browser implements it. Sometimes there are encoding issues (I do not see in your case).
The document at Test Cases for HTTP Content-Disposition shows behavior for various browsers.
To be safe with mobile browsers you should consider having the http request's last part be equal to the actual filename of the attachment, for example http://some.url/download/test.jpg .
Use apache mod_rewrite or similar to route such requests to your download script.