This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Is it safe to serve an image on the web without an extension?
I'd like to use something like <img src="advertisements/12" style="border: 1px solid"> in a page. FireFox won't display it, which makes me think I have to have a file extension for the file. Am I right here (for the other browsers too), or does FF like mime types?
EDIT
I've tried all sorts of stuff and it still won't work. I now put an extension on the file correctly (.swf for Flash, for example). I've changed the directory, etc etc. When I call file_exists(), The file is there, all happy and such, however I absolutely cannot get it to render on the page. It could either be a .PNG in an img tag, or a Flash object. Neither works. What am I doing wrong :-(
Also, if I rename a non-uploaded file to the file the script is looking for, that works fine, but the uploaded ones don't...
Yes, you should be able to.
Browsers initially don't look at the filename, they look at the MIME type listed in the Content-type header in the response from the HTTP server. If the content type is image/jpeg, or png or gif or whatever, things are good and it will happily render the image.
If there is no valid MIME type, some browsers will try to guess what the type is. They'll look at the extension of object being request, or they'll look at the first few bytes. If that fails, then you get a redex.
That used to cause some woes back in the early days of Firefox / Firebird, because it was strict about mime types and often refused to render something without a valid MIME type. IE made a guess, and so many sloppy web servers would serve up pages that would render fine in IE, but not in others. These days though, things are much better.
So, as long as your web server is providing the right MIME type when the img object is requested, you'll be good to go. If you are having problems, check what your web server is doing when "advertisements/12" is requested.
What is the server returning? The file extension isn't used for anything, really. The browser is checking for the Content-type header, which should be something like image/jpeg or whatever type of image you're serving.
This is used pretty often in sites which dynamically serve images, often from a database. I've seen plenty of image URLs like image.aspx?id=37 which, while it technically has an "extension" doesn't really mean that it's an image. It's all in the HTTP header values.
Providing a MIME type might help, although the server should theoretically be providing the correct one. If it's a specialized PHP (or similar) script that's serving up the image, you have to make sure you set the HTTP Content-Type header to the appropriate MIME type.
If you want to avoid using the <img> tag, you can use <div> in conjuntion with CSS backgrounds, but that's not going to help if the browser doesn't recognize advertisements/12 as any known image type.
2022 Edit:
Wow! Well, it worked good enough back then... But, for modern day detection there is https://www.php.net/manual/en/function.exif-imagetype.php ...with webp detection as of v7.1.
I found myself with similar image viewing problems after renaming images uploaded from web forms. Since I could have a mix of gif, jpg, jpeg, or png files I went looking at the file properties.
What I ended up doing was checking the MIME type (which is usually within the $_FILES array while processing the uploaded files) and appending an associated extension to the file name.
if($_FILES[$fieldname]['type'][$key]=='image/gif') {
$ext='.gif';
}
if($_FILES[$fieldname]['type'][$key]=='image/jpeg') {
$ext='.jpg';
}
if($_FILES[$fieldname]['type'][$key]=='image/pjpeg') {
$ext='.jpg';
}
if($_FILES[$fieldname]['type'][$key]=='image/png') {
$ext='.png';
}
List of common image mime types.
--Which did fix my problem as my browser was trying to download my images as binary files without the filename extension.
Server - Debian, Apache 2.2, PHP 5.3
Web Client - Kubuntu 11.10 ,Firefox
Related
I do not know how to frame the question. And I do not know how the below tag is working...
<img src="img.png?value=23"/>
This tag is working fine. And its rendering the image correctly.
Does the value=23 has some effect??? or It is been ignored by Browser??
I do not even know how to Google this!!! Is it like passing parameter to the Image??? If that is the case, how to retrieve the value attribute. Does the parameter has any sense
It depends on server, if you have png MIME type as text and you parse the files as if they were text files with php code then it has effect.
It really depends on configuration of server not a browser.
Morover, mod_rewrite can be used to change files that look like png to php files.
Adding parsing png files via php parser
AddType application/x-httpd-php .png
mod_rewrite
RewriteEngine On
RewriteRule ^([a-zA-Z0-9_\-]*)\.png$ img.php?value=$1
With these lineasdfasdf.png will be treated as img.php?value=asdfasdf
So in this case when you use $_GET['value'] on asdfasdf.png or img.php?value=asdfasdf. It will have effect.
If server is not configured to do such things and images are images(Yes i know it's briliant sentence) then it has no effect on common image.
To sum up.
It depends on server configuration not on the browser
If this image is dynamic in some way, then the server that's hosting this image must be generating the image from PHP code.
Take a look at the GD library, which lets you use PHP to generate images based on nothing or other images. The parameter must be passed to include that value inside the image (for example, an image that includes the text "123" or calculates using it somehow, for example a user ID).
Then an .htaccess on the server rewrites the extension of .png to .php (or maybe another one) to make it look like a genuine image to some libraries and crawlers, or scripts etc.
Another option, is that this is a simple image and that value is being ignored, or is just random to make sure the image isn't cached.
The value=23 only has an effect if the server uses it. The browser requests http://example.com/img.png?valud=23, so the server will see the parameter.
For example, with PHP, if your use $_GET['value'], and that variable changes what image is sent, then the value=23 is needed.
Parameters are often sent with images to specify a height or width, or to determine which image is loaded.
For this sample i don't know what does it mean
But it's possible to write
<img src="path_img.png?<?php time() ?>" />
to force your browser to download resource without using cache
It sure does!
For example, take a look at this piece of software that is intended to dynamically resize an image.
http://imageresizing.net/docs/basics
If done correctly, adding parameters to an image url could be very useful.
Edit:
As others point out, you need to ensure that the server knows how to handle the extra parameter. In this case it is intended to resize/watermark/rotate an image. It can certainly do other wonderful things.
value=23 is not ignored by your browser but by the server.
It's like passing parameters to the web server. For images it will be mostly ignored.
The arguments in a url are mostly used for getting some information about a specific item but can be used in more other ways. When talking about the images, the browser won't ignore the argument value=23 but the server you are using will.
But if the image is some sort of dynamic then it may be used in order to change the image's URL or other things.
I got a bit of a weird issue here. (Either that, or I'm just overlooking something stupidly simple.)
I have a file upload form, and I want it to only accept certain types of files amongst which MS Word documents. I added the .doc and .docx MIME-types (application/msword and application/vnd.openxmlformats-officedocument.wordprocessingml.document respectively) to the accept attribute of the file input field, yet when I hit "choose file", the .doc and .docx files are still greyed out as not allowed to be uploaded.
So, what am I missing? Any help or pointers would be greatly appreciated!
(And yes, I know the form-check isn't a good way to filter uploaded files. I've got PHP covering that, this is more of a convenience for the user, so they don't go and upload a disallowed file.)
Support of the accept attribute has been poor but is slowly becoming more common. On my Google Chrome 19, the element <input type="file" accept="application/vnd.openxmlformats-officedocument.wordprocessingml.document,application/msword" /> works so that the selection is limited to .doc and .docx files. Other browsers generally ignore such an accept attribute, though e.g. Firefox supports some simple cases like accept="image/gif".
In addition to this, browsers may map MIME types to filename extensions (which is generally what file systems treat as “file type” indicators) in different ways. Therefore, although the attribute may work in some situations, it might make things worse when the mapping is different.
I'm the MIME type for Word files likely isn't registered with the browser, so the Word file is being reported as application/octet-stream. In general, MIME type filtering in HTML forms does not work reliably, except for common image MIME types.
You could create a JavaScript solution to check the extension of the file.
I opened a image/x-png type image in new tab, but Chrome just downloaded it.
I googled it and found that Chrome doesn't interpret image/x-png as image file.
So, I want to edit my Chrome's MIME type mappings. Is it possible?
Too bad you have not answered my comment, so I forgot about your question and lost the bounty. I guess my answer is even a little easier to use for you because you do not need to click any context menus in order to see the PNGs directly in the browser:
Chrome extension Redirector can be configured to replace HTTP response headers. I created a rule replacing the Content-Type header for any URL ending with ".png":
Paste this JSON code into a text editor, save as png_rule.json and then in Redirector settings go to Rules Manager, click Files to open im-/export options and import the rule version 1:
[{"name":"x-png -> png","match":{"str":"\\.png$","type":0,"modi":false},"sub":{"str":"Content-Type","type":4,"modi":true,"modg":true},"repl":{"str":"image/png","decode":false},"enabled":1}]
From now on all your PNG files should be fine.
Update: replaced the simple pattern match by a stricter regex match as suggested by the author or Redirector.
Update 2: There are systems like Trac which produce URLs for PNG attachments ending in ".png", but really being HTML pages which only embed the PNG as part of the page. In this case we need to blacklist the hosts because otherwise the HTML page's content type would be set to image/png even though it should remain text/html. Because of Redirector's limitation that headers can just be overwritten for matched URLs and partial replacement, e.g. only png instead of x-png, is impossible, we need to use a rather ugly approach of explicitly excluding certain hosts in the regex match. E.g.
^https?://(?!([^/]+\.)?(?:trac\.edgewall\.org|freetz\.org)/).*\.png$
would exclude URLs containing either host name trac.edgewall.org or freetz.org. The full JSON to be imported into Redirector is rule version 2:
[{"name":"x-png -> png","match":{"str":"^https?://(?!([^/]+\\.)?(?:trac\\.edgewall\\.org|freetz\\.org)/).*\\.png$","type":0,"modi":true},"sub":{"str":"Content-Type","type":4,"modi":true,"modg":true},"repl":{"str":"image/png","decode":false},"enabled":1}]
Two test URLs failing (i.e. showing empty "images" instead of HTML pages) with the previous version of the rule without blacklisting and now functioning with the new rule including blacklisting are:
http://trac.edgewall.org/attachment/ticket/10804/changeset_show_files_3.png
http://freetz.org/attachment/ticket/1908/arris1.png
It is easy to add other URLs if you know a little regex or just play around.
By the way: For Trac URLs a good alternative would be to use the common part "/attachment/ticket/" for blacklisting. This way you could blacklist all Trac installations worldwide instead of a fixed hosts list. So this is rule version 3:
[{"name":"x-png -> png","match":{"str":"^https?://(?!([^/]+)?/attachment/ticket/).*\\.png$","type":0,"modi":true},"sub":{"str":"Content-Type","type":4,"modi":true,"modg":true},"repl":{"str":"image/png","decode":false},"enabled":1}]
Update 3: Redirector is no longer available in Chrome store, but historic versions can be downloaded from the old Redirector home page.
It seems that you can't edit your MIME type mappings, see "View As MIME Type" in Chrome or Firefox
This answer https://stackoverflow.com/a/8724758/962091 is of particular interest. The author has made and open sourced a Chrome extension to open files as different MIME types via an added menu item on right-click, though it does not provide a global handling mechanism.
EDIT:
The extension by default only has the options to open as text/html and text/plain, but you can add any extensions you like, including image/png, in the extensions settings. Here's a test image.
This bug was moved to Untriaged on August 13, 2012 in the Chromium bug tracker, so hopefully this will be fixed soon in Chrome as well.
There is a Chrome extension that can change the content-type and the disposition for any pattern, so it can be used to force png to display instead of download (but it is good for many other cases, I am using it to render txt as HTML): Modify Content-Type Chrome Extension
For some reason they have removed redirector from chrome web shop. You can find any version of redirector here
Here is json for .jpg .gif and .png formats:
[{"name":"x-png -> png","match":{"str":"\.png$","type":0,"modi":false},"sub":{"str":"Content-Type","type":4,"modi":true,"modg":true},"repl":{"str":"image/png","decode":false},"enabled":1},{"name":"x-jpg -> jpg","match":{"str":"\.jpg$","type":0,"modi":false},"sub":{"str":"Content-Type","type":4,"modi":true,"modg":true},"repl":{"str":"image/jpg","decode":false},"enabled":1},{"name":"x-gif -> gif","match":{"str":"\.gif$","type":0,"modi":false},"sub":{"str":"Content-Type","type":4,"modi":true,"modg":true},"repl":{"str":"image/gif","decode":false},"enabled":1}]
Apparently, Chrome does not have its own mime-handling database, but uses that of your desktop environment.
In my XFCE4-based environment, for example, the settings are controlled through the xfce4-settings app (xfce4-mime-settings specifically).
On a Windows desktop, you'd go through the "Default Programs" part of the "Control Panel", as described in (painful) detail here.
I have a web application that will display logos. Some of the logos will be in GIF format. Some will be in JPEG format.
I'd like to standardize a file naming convention, so that I can find the logo file given the company's Primary Key. For example "British Petroleum" has a PK of 1459, and their logo is stored in /Images/Logos/C1459
So my question is this:
Are the file extensions important? Can I just save the files, and strip off the .JPG or .GIF and expect all browsers to be able to identify and render the file? Or do some broswers rely on the file extension for identification?
I've tried this on a test machine with IE7 and it works fine, but I don't want to assume that all other browsers work the same.
EDIT:
A Follow up question. Hows does IIS determine the MIME Type of a extension-less file?
More important to a browser is the MIME type transmitted along with the file during download - historically, some did fall back to heuristics such as file extension or trying to calculate based on the bytes transmitted, but if the MIME type is correct, there would be no need.
You'll definitely want to test it in as many browsers as possible, but it should be fine. As long as the file format is correct and the MIME type is being conveyed properly, the browser should merrily display the image just fine. (A lot of sites will have "images" with URLs like: /images/dbimage.aspx?id=123)
Edit: More important to the testing than different browsers, actually, is different image types. If there are any image types that don't get sent with the correct MIME type, you'll want to identify those and either address them or disallow them.
This seems a bit back-to-front to me. Why not:
1) Convert all images to the same type when you first store them?
or
2) Search for a company's image using a wildcard search (ie match /Images/Logos/C1459.*) and load the file that returns a positive match. As you are using primary keys, you can be confident that you should only find one match for each company.
I have .txt files which are mostly (truly) html document (they have the header, body, html tags etc.). (I'm working in Windows environment here). I would like any browser to readily read them as html document (html document with normal .html suffix). Right now i have to rename the .txt file to be able to read it in the browser (Ex: myfile.txt -> myfile.txt.htm). Any trick we can apply to fool the browser right away?
Relative question: Is there any code i could add on top of those .txt file so that only .txt files with that code will be open as html document and seen as such by browsers? (code could be anything added with hexadecimal editor ot plain ascii). Thanks.
Since you're reading the file directly off of your file system (ie: using a file: URL rather than http: or something else) your browser is using the extension to determine the content-type of the file. How this mapping from extension to content type is made varies from browser to browser (and also from OS to OS to a certain extent).
First off, I should say that I'd be a bit afraid of making this sort of change. There's probably lots of code that has a hard-coded assumption that .txt maps to text/plain, so altering that mapping is likely to expose all sorts of nasty bugs. Caveats aside, here's what you need to do:
In Firefox, ExternalHelperAppService is used to determine the type of file: URIs. Note that one of the steps is to use a hard-coded list of extension to type mappings, which most likely has .txt mapping to text/plain.
In IE the file type mappings come from OS settings. It varies a bit depending on which version of Windows you're dealing with, but usually in the same general part of the settings where you choose which program to run for each extension you can also set a mime-type for each extension. (This is also the place Firefox looks in the "the Operating System is asked for a MIME type" step mentioned on the page I linked to above, BTW.) If you sent the MIME type for .txt to text/html you should get the behavior you want.
It is the HTTP headers which tells your browser what kind of data it is transfering so you have to edit the settings of your web server
Save the text with its htm-codes in WORDPAD as OPEN Document text.
Use in the name of the file the extension .htm.
This worked for me.