I'm seeing some strange behavior from some dynamically generated PDFs using the TCPDF library in PHP.
Standard lamp stack-- however, if you try to open the PDF from Windows with Acrobat Reader, it gives an error that the "file is damaged and could not be repaired". From Mac, Linux, etc. the file works fine, and opens fine. It also opens fine in Google Docs-- so clearly the PDF itself is ok.
Is it possible that the mime type (application/pdf) is causing problems in Windows?
Thanks
What browser on Windows? All? Or just one? My initial gut instict, is that the Windows browser is ignoring the encoding IF the content is being gzipped (Ignoring the Content-Encoding header). That's if you're even sending that header.
Open the file you downloaded in some text editor (Notepad, etc). The first few characters of the file should be %PDF-1. with another number after it. If it's not at the beginning, check to see if the file is gzipped (rename the file to blah.gz, and then run it through gzip to try to decode it). If that worked, then your problem is the browser ignoring the encoding.
IF it is ignoring the encoding, you need to not gzip the output of that PHP file. How you do that will depend on your server configuration.
Oh, and the application/pdf is the proper mime type. And the mime type is not your problem, since Acrobat is at least trying to open the file...
Related
When I attempt to navigate to the PHP script at http://localhost/project/admin, I expect to see the script results in my web browser.
Instead, I see a dialog box for downloading the file with the message below:
You have chosen to open <filename>, which is a: application/x-httpd-php from: http://localhost
What should Firefox do with this file? Open with... • Save... • etc.
Any idea what is going on?
PHP is not correctly installed on the server or Apache is not using mod_php
In the case of this happening in IIS. I would say that the mimetype is not setup correctly and that the server doesn't know how to handle the extension ".php"
It sounds like an incorrect Content-type header is being sent. This header sets the mime-type for the data the browser receives and, if the browser doesn't have a handler to render that specific mime-type, it will ask to open/save the file instead.
I would start by checking your PHP file for a header() statement and a mis-typed content-type.
I have form for file uploading in my website that i check mime-type of uploaded file to allow or refuse uploading it. It worked well until I've upgraded my firefox to 3.6.11 (in ubuntu). But now uploading Doc files is not possible. I checked the mime-type of file but it was 'application/x-php' instead of 'application/vnd.ms-word' or other msword mime-types.
I use
echo $_FILES[$fileName]['type'];
to see the mime-type. I upload the same file from firefox 8 and firefox 3.6 and the output of above code was:
FireFox 8: application/vnd.ms-word
FireFox 3.6: application/x-php
Is it a bug of firefox or I have to change my codes?
I use PHP.
$_FILES[...]['type'] is just arbitrary, user supplied, best-guess, unreliable (as you see) information supplied by the client which may or may not have anything to do with the actual file. Never use it.
Try to detect the MIME type yourself on the server. For example techniques, see How to get the content-type of a file in PHP?.
I'm building a web app with PHP that uses Excel Writer (XML) for PHP to create an Excel file that the user can download. I've taken a look at the source code for the library, and all it does is echo the generated XML to standard output. Although the file being generated is an XML file, I specifically give it a name with a ".xls" extension so that after it's been downloaded the end-user can double-click it and it will launch Excel on their system and open the file successfully.
This works correctly when downloading the file with Firefox, Chrome and IE, but not with Safari. For example, if I set the name of the file to be 'File.xls', this is the name of the file that gets downloaded. But with Safari the name of the file ends up being 'File.xls.xml'.
The server is running Apache on Mac OS X. I thought that might matter as I'm guessing that the problem has to do with MIME types on the server, but I'm not at all sure. Perhaps I can do something with the link that appears on the page, or perhaps I need to edit a configuration file for Apache? Any help is appreciated.
You might be right, it could just be the MIME type that needs setting.
Try putting
header("Content-Type: application/vnd.ms-excel");
before the output code, that should force the browser to see the data as an Excel file.
If the code is setting Content-Type already and it's conflicting, then search the script for "Content-Type" and try changing it.
Also, if it's an XLSX file, then there's a different MIME type - application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
I am using php's imagejpeg to save a GD image resource to a file, doing this:
imagejpeg($im, '../images/' . $image_id . '.jpg');
It works fine, but according to my browser, it tries to read the file as text/plain:
Resource interpreted as image but transferred with MIME type text/plain.
Is there a step before saving the file that I am supposed to do to make sure it's using the right mine-type?
I am using windows (XAMPP), could it be a Windows issue?
EDIT: nope. I just tested in a linux server.
As far as the actual displaying, it's just plain html .
My upload code is supposed to saves= the file as a plain jpeg in the server. It's just not saving it with the right mime type.
Thanks
AFAIK, the Apache server - in standard out of the box configuration - should sent content-type headers purely based upon file extension. Apache shouldn't even even be looking at the contents or how it was originally generated/stored.
On my out-of-the-box Apache2, the file conf/mime.types contains the line:
image/jpeg jpeg jpg jpe
which ought to do it, right?
Can you post a test-case, say, a simple html page with two img tags: one for your generated image, and one for a standard image that seems to work fine?
One last thought: Does it occur in all browsers? Maybe it's a browser issue, not a server one?
It sounds like you're dumping the contents of the file to the browser and not actually telling the browser what type of file it is. Try adding a Content-type header before you output your image to the browser:
header('Content-type: image/jpeg');
Are you sure you aren't using the wrong file-extension name?
Otherwise, just put an normal image in the server and make sure the mime-types are properly configured.
It could also be that your image data from the manipulation is corrupted.
I am storing files into an image field in SQL server storing the string in hex after converting into using:
unpack("H*hex", $datastring);
If I read from the database and write to a file, then open the file locally I can open it up just fine. But if I try to send the file as an attachment to the browser the file becomes corrupted and unreadable. Currently, the files in question are PDF and MSWord documents.
I am setting content-type to the appropriate MIME type for the files and setting content-disposition to attachment. I've tried various ways of streaming the file including dumping the string directly from the database and writing first to a file then reading the file (either line by line or with readfile()).
I am using a slightly customized version of the Zend framework, but I'm not sure if that is causing any issues. What should I do to send files to the browser?
How do you serve them?, in theory if you are using MVC, you need to disable the view at the end of your controller to avoid extra content being inyected at the bottom of your file.