I have a webapplication where I read images from a sql 2008 database through the 'new' filestream functionality.
The thing here is, when you right-click and choose save image, IE gives error 800700de while with Firefox it works fine.
The img src is set to a php document which takes a few params to know where to look in the database and then prints the binary data. Please note that displaying the picture works fine in both browsers, this is not the issue. The issue is what I mentioned above.
Any idea why this could be? Is there any solution or a workaround for this?
Are you building the headers? If so that may be it. What headers are you sending?
Possible appropriate headers via: http://www.electrictoolbox.com/image-headers-php/
GIF:
header('Content-Type: image/gif');
JPEG:
header('Content-Type: image/jpeg');
PNG:
header('Content-Type: image/png');
It sounds like IE is going ape because it doesn't quite trust that your file is an image.
If you continue to have problems even after setting the Content-Type headers as others have explained, you can further fool the browser into thinking your script is an image by using a .png or .jpg extension, and then forcing that file to be executed as PHP.
For example, in .htaccess put this to disguise a PHP script as "image.png"
<Files image.png>
ForceType application/x-httpd-php
</Files>
Related
I am working on a project which creates a KML File (just like an XML file, but used for Google Earth). Whats interesting is when I link to the newly created file, on my local machine, running XAMPP, the file is downloaded automatically, however when I move it to my web server (Linux, Fedora 8 on EC2) the link just loads the KML file in the browser as if it was an HTML file.
How can I force it to download the file instead of viewing it in the browser?
Here's how to link is displayed with PHP,
echo "<a href='$currentTime.kml'><img heigth=\"15px\" width=\"13px\" src=\"images/KML_Icon.gif\" /> Download</a>";
Any advice would help, thanks!
What you need to do is to specify the headers so the Browser knows what to do with the information that you are sending. So before you send anything to the browser you will need to specify the headers.
If you are linking to a specific file, then you will have to create a little "download manager" that will do this for you.
<?
header('Content-disposition: attachment; filename=the-name-you-want-them-to-see-in-their-download.pdf');
header('Content-type: text/xml'); //Since KML files are based on XML this is probably the best Content type to send to the user.
readfile('the-file-you-want-to-present')
?>
That should do it.
Thank you for your guys' input, but Oded had the answer regarding the mime types.
On the server there's a file called mime.types which didn't contain the mime type for a KML file, I added in
application/vnd.google-earth.kml+xml
And it now downloads the file instead of loading it in the browser, by the way apache needs to be restarted once you have made the changes.
I had this a long while ago, I used a method similar to this:
http://webdesign.about.com/od/php/ht/force_download.htm
I have a web app which performs a character encoding conversion on .ssa files (SubStation Alpha - subtitle files basically). The MIME type of these files is text/plain. When the app performs the conversion it creates a link to download the new file. In Safari this works perfectly. However in Chrome when you click the download link it attempts to save the file as download.txt no matter what the actual filename is. In Firefox (beta) it tries to save it as something like kP3844h1.txt.part. How can I tell these browsers just to use the filename that is linked? In all cases the contents of the file is correct, it's just the name in the browser's "Save As..." dialog that gets screwed up.
Currently my .htaccess looks like:
AddType text/plain ssa
<Files *.ssa>
#ForceType application/octet-stream
Header set Content-Disposition attachment
</Files>
I've tried with both of the <Files> lines uncommented, and with either one commented on its own, but none of those options gives me the solution I'm looking for.
Also, the app is written in PHP, so if there's something I could be doing in the PHP code instead of messing with the .htaccess, I'm open to suggestions.
Use Content-Disposition attachment; filename="$actual_filename.txt" as header. Replace $actual_filename.txt by the actual name of the file. I have no idea if this is possible in the Apache configuration, but if you pipe the files through PHP, you might be able to set the header with the header function.
I've uploaded an MS powerpoint file to my server, and I'm trying to use Google Docs viewer (http://docs.google.com/viewer) to display it on a webpage.
The file is available here:
http://elgg.wamped.org/test.ppt
If I invoke the docs viewer with the above URL, it is working as expected, see:
http://docs.google.com/viewer?url=http%3A%2F%2Felgg.wamped.org%2Ftest.ppt
But when I'm trying to serve the same file through a very simple php script to the viewer, it fails rendering with the not too helpful error message: "Sorry, we are unable to generate a view of the document at this time", see:
http://docs.google.com/viewer?url=http%3A%2F%2Felgg.wamped.org%2Freadfile.php
The script that serves the file is as follows:
<?php
header('Content-type: application/vnd.ms-powerpoint');
header('Content-Disposition: attachment; filename="test.ppt"');
readfile('test.ppt');
?>
I've tried playing around with various header fields like Pragma and Cache-Control, but nothing helped. I also tried slicing the output file and echoing in chunks, that also did not do any good. Checked the apache log on the server, checked the response headers, everything seems fine to me.
Any ideas what am I doing wrong here?
EDIT: Although I haven't found a solution to this issue, I stumbled upon a site that does the same (or seems to do more than that, actually) as Google Docs Viewer. http://embedit.in has support for a wide range of file types, has an API, and does the job nicely, so I'll just probably go with that one. However, out of curiousity, I'd still like to know what is wrong with the piece of code below. So any suggestions are more than welcome.
Have you tried naming the php file with a .ppt file extension instead of .php? Whether or not your server will process php code in a file that doesn't have a .php file extension is another problem. But Google Docs may simply say NO to loading any file with a .php extension on it.
Capitalize the T in Content-Type. I also provided the Content-Length header. My filehandler works now.
It looks like you might be missing some headers. You might also want to see if the file is in the same directory as readfile.php, because google might store each file on a remote server.
I am using a flash player to play some mp3 files. At firefox it loads them normally but at IE it doesn't. When i go to the url of the .mp3 file it shows the source code of the mp3 (instead of offering eg to download). So i used a small script to fix it:
$url = $_GET['url'];
header('Content-type: application/force-download');
header('Content-Transfer-Encoding: Binary');
header("Content-disposition: attachment; filename=demo.mp3");
readfile($url);
I would like to ask you if the above is safe. Moreover, does the server losses bandwidth by this way? And finally, does it influence the server's resources?
Thanks.
No, that's not safe. If you had your database password in database.php and I entered database.php as $_GET['url'], your script would send me that PHP file with your password in it.
Yes, this would use up bandwidth and some server resources.
It's not safe, and it shouldn't be necessary for you to do this way.
In addition to the security implications #ceejayoz outlines, if the allow_url_fopen PHP setting is enabled, it is also possible to insert any URL into $url. That way, your server could be easily misused to stream large amounts of data from other servers, with all kinds of implications.
This method of serving files should be used only when really necessary. It consumes more resources (because an expensive PHP process has to be started) than requesting a static resource through the web server.
It should not be necessary in your case anyway. It sounds like your web server is not serving the correct content-type header along with your MP3 files. That is what you should fix.
Maybe, if you're on Apache, adding a .htaccess file to the directory the MP3s are in with the following content:
AddType audio/mpeg .mp3
already fixes the problem. If it doesn't, but the force-download thing works, then try
AddType application/force-download .mp3
Your actual problem is that you are not sending the content-type header to the client when you serve the mp3 file. Ensure that you are setting the content-type header prior to sending the contents of the mp3 file.
If you're serving them directly from your web server, without a script, you simply need to configure the content-type in your web server's configuration.
For Apache, you can configure this in an .htaccess file:
AddType audio/mpeg .mp3
Yeah there is definitely a security risk here since you aren't validating/sanitizing the requested file path. So make sure you check that before sending files down to the user!
Although this will use bandwidth and server resources, it would be minimally more than downloading files regularly. The only extra overhead is processing/running the PHP. You probably won't notice a difference.
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.