I'm using PHPExcel to generate Excel files on the fly within my PHP application. I'm using the Excel2007 format.
When a user visits the URL that creates and forces the download of the Excel file, everything works great in all browsers except for mobile Safari (iPhone and iPad).
Here are my headers and the readfile method:
header('Content-type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet');
header('Content-disposition: attachment; filename=' . $file_name . '.xlsx;');
header('Content-Length: ' . filesize($path_to_file . '.xlsx'));
readfile($path_to_file . '.xlsx');
When I browse in mobile Safari to the URL that is supposed to download the .xlsx file I can actually see the tabs representing each worksheet of the file, but I don't see the actual data like so:
Furthermore, there are two additional weird behaviors I'm encountering with this:
If I download this file on a desktop browser and email it to myself and open it with the Mail app in iOS, the file displays correctly.
If I then take that attachment from the Mail app in iOS and import into, say, Dropbox, it does NOT display properly (it displays the same as the screenshot above).
In Chrome, the file downloads properly and opens in Excel or even Numbers as expected, but in the console I see this message: Resource interpreted as Document but transferred with MIME type application/vnd.ms-excel:
Also, per the PHPExcel documentation, in place of readfile I have also tried:
$objWriter->save('php://output');
That, however, produces an error in mobile Safari that reads:
OfficeImportErrorDomain Error 912
To eliminate the Content-type as being the issue I've experimented by adjusting the Content-type to other values (such as application/vnd.ms-excel or even application/download). Unfortunately (though not surprisingly) those don't work either.
Any guidance is greatly appreciate.
I use ->addHeaderLine('Content-Type', 'application/octet-stream'). Otherwise Safari displays error.
Although this header makes it to display xlsx file in browser, not downloading. I haven't found any solution to force mobile Safari to download.
Related
I'm using Retrofit 2.0.0-beta2 and I need to download some files from my PHP server. My first approach which worked was to directly use the GET method from its relative server path and I was getting the correct bytes.
Now I've tried something more secure that delivers the file to me based on some checks. It automatically fetches the file path from the DB and checks if the user session is correct. This works in browser tests, both Chrome PC and Chrome from Android correctly download some photos.
I'm serving the file using the X-Sendfile header like so:
header("X-Sendfile: $file_name");
header("Content-type: image/jpeg");
header('Content-Disposition: attachment; filename="' . basename($file_name) . '"');
The Android-side call looks like this:
#Streaming
#GET("/card/download")
Call<ResponseBody> getCard(#Query("filename") String filename);
All I'm getting when opening the files is the echoed text response from server. Is there any way I can receive the "correct" files?
Apparently there was some sort of problem installing the mod.
I also updated OkHttp to version 2.7.0
I am using PHP to fill a PDF form, which I would like to output to the browser. I am using the function found here: http://koivi.com/fill-pdf-form-fields to create an xfdf file. I then use the following code to fill the form and output the resulting file to the browser:
header('Content-type: application/pdf');
header('Content-Disposition: inline; filename="filename.pdf"');
passthru("/usr/local/bin/pdftk forms/pdf_form.pdf fill_form filename.xfdf output - ");
When I open the PDF created from the browser, I get an error from adobe pdf reader that says "Adobe Reader could not open 'filename.pdf' because it is either not a supported file type or because the file has been damaged (for example, it was sent as an email attachment and wasn't correctly decoded)." Opening the same PDF in another reader does not give the error, but my users will be using acrobat.
By way of contrast, if I change my code to the following:
header('Content-type: application/pdf');
header('Content-Disposition: inline; filename="filename.pdf"');
passthru("/usr/local/bin/pdftk forms/pdf_form.pdf fill_form filename.xfdf output filename.pdf ");
I can open, read and edit the resulting PDF from the tmp folder. It seems that the 'output - ' option is somehow corrupting the PDF.
My question is this: Am I doing something wrong? Is there some piece of code that I am missing or a better way to accomplish this?
PHP version: 5.3.19; Server OS: Mac OS 10.7.5; Client OS: Mac OS
10.7.5; Browsers tested: Chrome, FireFox; Readers tested: Adobe PDF Reader, Preview; PDFTK version: 1.4.5
Use <?php ... for instance without final ?> so you are sure no final whitespace, especially newline is written after the PDF output.
I did an xml file and force download it by these headers:
header('Content-disposition: attachment; filename="export.xml"');
header('Content-type: application/xml; charset=utf8');
readfile('export.xml');
But before the download I see a dialog that this file can be harmful for my computer? How to get rid of this dialog? Maybe my headers is wrong?
upd Well, can do nothing, I did a test on my test-hosting, u can check it here: site with generation link, and an xml file as is: export.xml
Try changing application/xml to text/xml. Probably your browser thinks that application means executable.
Try this :
<?php
header('Content-disposition: attachment; filename="export.xml"');
header('Content-type: "text/xml"; charset="utf8"');
readfile('export.xml');
?>
Note: This does not solve your issue, however it did solve an issue I had on my computer giving that notice (windows, chrome, apache webserver, PHP 5.4.10). I leave it here for future visitors.
Some browsers do not only look for the headers but also for the "filename" in the URL.
For example if you download a PHP file that contains XML, the browser might identify it as a dangerous file (because it can be executed on your system or is not within some whitelist or what not):
http://example.com/xml-download.php
A simple solution is to make this file not end with .php any longer, for example by adding a ?:
http://example.com/xml-download.php?
And continue with that to even signal the filename that way:
http://example.com/xml-download.php?export.xml
(the last one is not necessary but can be useful especially with some older browsers)
I redirect the visitors in my website from page A to page B. In page B I expect users to get the downloaded PDF file (to be downloaded when page B is loading).
I have taken the code from another article (see a previous question answered here) and my code of page B is the following:
<?php
header('Content-Disposition: attachment; filename=nature.pdf');
header('Content-type: application/pdf');
$fn=fopen("/wp-content/nature.pdf","r");
fpassthru($fn);
?>
The output is not by opening a download dialog box, instead some unreadable characters are displayed in browser such as the following (I have just picked up a small sample below):
%PDF-1.4 %���� 3 0 obj <>stream x���MK1�o�+�$zIg&�� V=T�=Xo����K��i+#V�yx3��(BX�pW`
Server: OS Linux; PHP version: 5.2.17
The visitor -> Browser: Firefox; OS: Windows 2000
Is it possible to fail due to the old OS on client side? If not, does anybody know a solution how to force the download? Any help would be highly appreciated.
Thanks.
Try it with the Content-Length header:
ob_clean(); ob_start();
header('Content-Disposition: attachment; filename=nature.pdf');
header('Content-type: application/pdf');
header ("Content-Length: ".filesize("/wp-content/nature.pdf"));
readfile("/wp-content/nature.pdf");
exit;
There was a quirk in the really old browsers when Content-disposition was first being introduced, some of the really old browsers wouldn't show the "Save As" dialogue unless it couldn't recognize the type of file you were trying to open. Try setting the Content-type to nothing (or something unrecognizable), and see if that'll force the older browser to pop the save-as dialogue.
header('Content-type: ');
If that works, then I'd suggest adding in a line of PHP to detect whether or not they're on an old browser before running that line, as modern browsers will use that header to determine what program the file should be opened with.
I have a bit of a problem with streaming MP3s in IE and Chrome (it works fine in Firefox)
We have a voicemail server. The web app streams the wav file by converting it on the fly to MP3 (using lame, not great, but we have to do it is this way because of limitations of asterisk) and then outputs the content as a binary stream.
header("Content-Type: audio/mpeg");
header("Content-Transfer-Encoding: binary");
header('X-Pad: avoid browser bug');
header('Cache-Control: no-cache');
$file->readFromInbox($f);
The MP3 audio player we're using is: http://wpaudioplayer.com/standalone/
If the file is (I think) less than 100k in size, the audio streams fine and the MP3 flash audio player status bar is updated(the seconds go up, and the bar moves along).
However, if the file is bigger than 100k then there is a problem. The audio plays in IE7/8 and Chrome but the status bar doesn't change. It continues to say 'Connecting...' even though the audio is being played. Odd.
In Firefox, I have no problems.
What could be the problem? Why does firefox not have any problems but IE and Chrome? Do I need to specify the size of the file being streamed? (Which isn't possible as the file is being converted on the fly and being outputted straight away because of the passthru command)
Thanks guys!
Convert the file first and store it as a tempfile. Then send that file along with the Content-Length header.
A temp file cam be created with this:
$tempfile = tempnam('/tmp','mp3')