In my site, I give an option to upload images with .jpg and .JPG extension. They both work and I can see both on the server itself.
When I try to see in the browser the photos with the .jpg extension by calling them name.jpg, they work. When I call to the othername.JPG (which is called that way on the server) it does not work and does not show it. othername.jpg does not work too.
I suppose your web server is not configured to send the Content-Type: image/jpeg HTTP header for such files. It's possible that some browsers refuse to display them as pictures if the MIME type does not match. If you happen to be using Apache, you can fix it yourself in an .htaccess file:
AddType image/jpeg .JPG
You should also consider that you cannot count of URLs being case-insensitive: FOO can equal foo... or not. Use always the exact case and save yourself future problems.
Edit:
Before misconfiguring random stuff, you can follow this checklist and see what fails exactly:
Is the URL valid? Foo.jpg is not the same as foo.jpg.
Does the browser receive the file? Firebug should tell you.
What's the HTTP response code? Firebug should tell you.
What's the Content-Type header? Firebug should tell you.
Common status codes:
404: the file could not be found. Most likely, your URL is wrong.
403: you are not authorised to see the file. It can be a permissions issue.
500: generic server error code. You should open your hosting service control panel and have a look at the error log.
Your using linux/apache right? make the filenames lowercase. its the default for them to be accessed on linux.
try to check the contents of that file, maybe your script is messing up JPG uploaded files.
if that doesn't work maybe it's from your system .. an .htaccess
Look in error logs for anything that is related to this file.
Related
I'm getting below error when uploading a new product image for my Magento shop.
Resource interpreted as image but transferred with MIME type text/html
Is there a reason why this is happening?
This might well occur if your image path is set incorrectly. For example relative to current directory "images/myimage.gif" vs relative to web root "/images/myimage.gif".
The reference to "text/html" might suggest you have an error being returned by the server.
I noticed this problem appearing in my JavaScript Console log. It was a simple case of a CSS file looking for a background image that didn't exist and the server sending a 404 error message in its place.
One needs to serve the images with the proper MIME type -
Add this line into the .htaccess file (assuming it's apache2 httpd):
AddType image/gif .gif
hint: mod_rewrite might require an exclusion for images:
RewriteCond %{REQUEST_URI} !\.(png|gif|jpg)$
RewriteRule ...
... everything else might be 404 indeed.
I had the same problem once, because of capitalization.
My Colleagues were working on a Mac and added some camel-cased files, but it showed up lowercased in CSS. This works fine on Mac, but I was working on Linux.
Mac doesn't distinguish filenames having different cases but Linux does. Most servers out there run on Linux.
example:
epicimage.jpg !== EpicImage.jpg
Thanks to the Chrome Dev Tools, the problem could be found very easy. Simply clicking on the image url showed me our 404 page. Mystery solved :D
Please check extension of your image, whether the program used create the image labels its extension with capital letters or small letters, some servers read them different.
I checked out basically every similar question on StackOverflow trying to solve a similar issue.
After all the attempts at altering my htaccess file and inserting php head arguments, what fixed it for me was ...just changing the capitalization on the picture's name.
Ugh.
(It was working fine in the same browser local-hosted, too... so of course I wouldn't think that was the issue initially.)
After a lot of research, I have found the problem is caused by a combination of things resulting in the server not knowing what type of document it is and getting mixed up between encoding types such as UTF-8 (or something like that)
So, in .htaccess, change the comments round so you have the following, giving a default character set of UTF-8.
############################################
## Prevent character encoding issues from server overrides
## If you still have problems, use the second line instead
#AddDefaultCharset Off
AddDefaultCharset UTF-8
This stopped the correct error shown in google (thank you mr google):
"resource interpreted as image but transferred with mime type text/html"
And the made the images show up in other browsers (where there was no error shown).
My issue was with this line in the CSS
background-image: url('');
Which should have been:
background-image: none;
For me my path was set incorrectly relative to the css file that was trying to pull the image from that triggered the error in the console.
I had to go out 2 directories and then into the one that had my image.The .. before the slash brings you out of a directory. Each . brings you out one more directory.
ex. url (../Folder/ImagesFolder/image.gif)
If your image path and case-sensitive filename is set correctly, and if you can't modify your server's .htaccess file, encoding the SVG as a data URI is a front-end solution. css-tricks.com explains how:
http://css-tricks.com/using-svg/
This happened with me when I was including SVG image via img tag. If you are including SVG image via tag you need to switch to Object tag instead:
<object type="image/svg+xml" data="imageFile.svg">
Test SVG Logo
</object>
For me, this mime type error showed only when testing Safari 4.05 per client requirements, and only in the console. Ultimately this was caused by Safari handling the javascript styling element.style.backgroundImage="url()"; ungracefully. Evidently, Safari was looking for that empty url, so per Strixy and stevecomrie, "none" is the better choice. This is essentially the same issue as noted above as near duplicate of Resource interpreted as other but transferred with MIME type text/javascript?, wherein a <script src=""> was the culprit.
For magento2 Users
If you have modified this file app/etc/di.xml
with following
<item name="view_preprocessed" xsi:type="object">Magento\Framework\App\View\Asset\MaterializationStrategy\Copy</item>
make sure the path string is Case Sensitive (CaseSensitive for non Windows OS)
If you are facing 404 errors after magento2 Install in Ubuntu.
Install and Enable rewrite module
a2enmod rewrite
Then Edit
/etc/apache2/sites-available/000-default.conf
Add following lines at the End
<Directory "/var/www/html">
AllowOverride All
</Directory>
Maybe images didn't have read permission
I also got this problem, when i use TinyPNG to compress images, i got this error message "Resource interpreted as Image but transferred with MIME type text/html". Then i add images permission, it works.
image is sent with wrong headers, add headers to image type via .htaccess
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 have a valid link that goes to a picture located on my web server. It is a simple jpg image, I can copy and paste this link into my web browser and it loads fine. The issue comes in when I try to call a few php functions on the image... such as getimagesize or fopen... they both return 404 errors even though the image is there. Does anyone know that could be causing this?
Thank you for your time.
Are you using a local path? Or a full URL?
If full, do you have the protocol (e.g. "http") in front of the address? Not having the protocol might make PHP look for the URL in the local scope, which results in the image being not found.
EDIT:
Have you made sure the allow_url_fopen and allow_url_include are enabled on the new server?
Is allow_url_fopen enabled? Your installation may not allow opening files by URL.
var_dump( ini_get('allow_url_fopen') );
What happens when you look in your webserver's error log? This will tell you why the URL is returning a 404.
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'm serving up Zip and PDF files on the fly via PHP using an output such as:
header('Content-Disposition: attachment; filename="'.$project->name .'.zip"');
echo($zipfile->zl_pack());
I can't find any reference to these downloads in my APACHE logs though. Is it not logged due to being dynamic?
Do I need to actually write the file to the webserver and then serve the result up to get it logged or am I missing something?
Cheers,
Niggles
Correct. httpd does not look at outgoing headers for logging. error_log() will send a message to httpd's error log, but there's no way to put something in the access log.
The request to the PHP program that generates that header should be logged. The filename mentioned in the content disposition header won't be.
I believe mod_perl would allow you to add custom logging, I don't know if mod_php provides a similar feature.
As a workaround you could use mod_rewrite to have the *.zip file logged and still served it through PHP without actually writing it to the filesystem, the client will have to send two requests though.
1) Change your current script so that it doesn't produce the file, but instead puts the parameters needed for the file creation in the session; instead of the current header and file content you would put header('Location: '.$project->name .'.zip');
2) This would cause the second request. Since the requested file doesn't exist yet, you would use mod_rewrite to change the request to a *.zip file to the same or some other PHP script that reads the parameters from the session and produces the file just like you're doing it now. If you use the same PHP script, you would additionally let mod_rewrite add some parameter like "?action=produceFile" to the request and then test for that parameter in the script.
This way you would have two nice entries in your Apache log without having to physically save the file (and probably delete it later).
FYI I found a really good work-around.
Part of the problem was that we wanted to force a "save as" dialogue as many of the users get confused as to where the file gets saved. So this is why I went the
Content-Disposition : attachment
method.
A better method which still invokes the dialogue is to add this to .htaccess
<Files *.zip>
ForceType application/octet-stream
Header set Content-Disposition attachment
</Files>
write the Zip to the fileserver and redirect the page to the zip.
Sure I have to cleanup every night, but it gets logged and it still forces them to choose where they download the file (on pretty much everything but Safari [ there's always one ]).
Cheers,
Niggles