Let's assume that I want to add a favicon on a dynamically generated page (specifically an ADF Faces page, but this is irrelevant). I can't modify a tag of my resulted html.
So I try to add a http-header in servlet header. I want my header to be identical to html head element:
<link rel="shortcut icon" href="http://foo.com/favicon.ico">
I'm adding it this way:
httpResponse.addHeader("Link", "<http://foo.com/favicon.ico>; rel=\"shortcut icon\"");
And in my browser I see this header in response:
Link: <http://foo.com/favicon.ico>; rel="shortcut icon"
But, unfortunately, this does not have any effect in IE or Chrome. Anyone tried to achieve the same thing? Am I doing something wrong? Is that should work at all?
And the answer is: this method relies on proposed standard (a draft) that is not implemented yet (thanks to Salman A for pointing this out).
Though it would be great if it worked.
Yes Link headers have been a defined standard in RFC 5988 since October 2010 but the only link relation I've seen working are for stylesheet and only in some browsers at that.
Also see: HTTP Header Stylesheets
What #dragn is suggesting is perfectly viable, and in spec why the browsers aren't adopting is beyond me. There are some other useful relations like prefetch, bookmark and glossary to name a few. The least they could do is notify the user that links exist and provide it as a drop down or menu. Maybe a plugin is what is called for to show the browser vendors what we want it to do as it seems they are all confused. Any suggestions?
For now I guess we have to wait till 2020 for this feature to become available which seems to be the trent.
Yeah yeah "draft"..
anyway..
If you want to see how you can use it in-Practice, here is an example (taken from icompile.eladkarako.com)
<ifModule mod_headers.c>
Header set Link <http://icompile.eladkarako.com/favicon.ico>; REL="shortcut icon"; TYPE="image/x-icon"
Header set Link <http://icompile.eladkarako.com/favicon.ico>; REL="icon"; TYPE="image/x-icon"
Header set Link <http://icompile.eladkarako.com/img/apple-touch-icon.png>; REL="apple-touch-icon"; TYPE="image/png"; sizes="316x316"
</ifModule>
It will work in current Chromium/Google Chrome/Google Canary,
(and for sure if you set the switch for advance web-features in chrome://flags)
Related
My favicons are not showing up across browsers after I uploaded my website files onto the server. I have tried the following solutions on stackoverlow and nothing worked:
cleared cache on browsers
renamed the href <link href="img/favicon.ico" rel="shortcut icon"
type="image/x-icon" /> to something else, "favicon.ico",
"favicon.ico?"
Does anyone have any suggestions?
Thanks..
Perhaps try the following:
Place the file in the root - some browsers automatically look here for the favicon so may as well put it there if you can;
Drop "shortcut" - it is not a valid relation and isn't required from IE9 anyway (see: https://mathiasbynens.be/notes/rel-shortcut-icon). It may be complicating parsing. If needed to support IE8 and earlier, perhaps try a separate declaration.
Check that you have declared the "profile" in the head.
Consider adding variants for cross browser and purpose support (see: https://css-tricks.com/favicon-quiz/ - old, but shows issues).
Personally, can't wait till they all support svg.
TL;DR
I've read through many questions on Stack Overflow on this issue and I've tried to follow the given advice. Still, my CSS stylesheet will not work in Chrome/Safari but it can work in Internet Explorer.
The only odd thing that I can see about my scenario is my server is returning all files as of type application/octet-stream. I cannot change this aspect of the server. Is there something I can do to interpret my CSS file as a stylesheet in Chrome/Safari and IE?
I have an embedded web server project that I am working on. I have very limited control of the server software and the ability to make page-level settings. All I can do is create static HTML, CSS, and image files that are compiled into the server application.
As such, all files that are returned from the embedded server are declared as application/octet-stream in the HTTP header. This produces warnings in Chrome but no errors.
Initially, I had a problem loading this style sheet in Chrome/Safari but it would work in IE. After reading through a couple questions on Stack Overflow, I found that I needed to change my stylesheet declaration from:
<link rel="stylesheet" href="/styles/index.css">
to:
<link rel="stylesheet" type="text/css" href="/styles/index.css">
When I made this change Chrome & Safari still failed to process the CSS file but IE also started to ignore the stylesheet.
Oddly, if I do not declare a DOCTYPE on my HTML document I can get linked stylesheets to work in all of my browsers. This is, however, not a desirable solution.
My guess is this issue has something to do with the HTTP header declaration and that it doesn't match the type declared in the link element.
What can I do to get this stylesheet to work in Chrome, Safari, and IE while following good web development codes-of-practice (i.e. using doctypes on my HTML files and not embedding the style code in the HTML headers?)
For clarity sake, the relevant CSS/HTML code is shown below.
index.css
html {height:100%}
body {margin:0;min-height:100%;position:relative}
iframe {width:100%;height:100%;border:none}
.hdr {min-width:765px;overflow:auto}
.logo1 {float:left;margin:4px}
.logo2 {float:right;margin:4px}
.menu {position:absolute;top:70px;left:0px;bottom:0px;width:175px}
.content {position:absolute;top:70px;left:175px;bottom:0px;right:0px;}
index.htm
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<link rel="stylesheet" href="/styles/index.css"> <!-- Removed the type declaration so that this would at least work in IE9 //-->
</head>
<body lang="en-us">
<div class="hdr"><img class="logo1" src="/images/logo1.png" alt="Logo #1"><img class="logo2" src="/images/logo2.png" alt="Logo #2"></div>
<div class="menu"><iframe name="menu" src="/menu.shtm"></iframe></div>
<div class="content"><iframe name="main" src="/home.htm"></iframe></div>
</body>
FYI, this is a new project that is being developed from an existing one. The original project did not declare a DOCTYPE on the HTML files. Therefore, all page data was loaded and executed in the browser in quirks mode. Furthermore, the index.htm originally consisted of multiple frames within a frameset.
I am trying to update this application, using correct, and up to date methods for developing web pages. I can make this application work, but I feel that this would be at a sacrifice of future-browser compatibility if I have to rely on browser quirks mode and framesets.
I have tried to close the link tag but that doesn't help. Technically, this shouldn't be an issue since this document is declared as an HTML5 document, rather than XHTML.
It's certainly due to the application/octet-stream content type. I can re-create the issue on my end. Soon as the content type is set to text/css your HTML/CSS load fine.
As a workaround you can use <style> tags for you CSS if you can't get the server to send the correct content type.
I hate to have to answer my own question this way but the problem was most certainly with the fact that the server was returning a content type of application/octet-stream within the HTTP header.
After discussing the issue with management we had to update the code associated with the HTTP processor. This is code that is part of a third-party RTOS and we have been extremely hesitant to making any changes to this code.
However, in this case the need has out-weighed that desire. I've integrated the necessary changes to fix the HTTP header to return a content type of "text/css" for cascading style sheets. All is now right with the world.
I think I'll just chime in here. Not to answer the question, but to confirm the issue and perhaps help people with similar problems.
I had the same problem: an external css file was loaded alright, but it was not applied in Chrome. (Safari and FF were ok about it). So, same problem, slightly different cause.
It turned out that because of a bug in the webserver code the HTTP response contained two Content Types, 'text/html' and 'text/css'.
The solution was to remove the faulty 'text/html' line. It seems Chrome is pickier than other browsers about response headers. Which I suppose is legitimate, but a warning would have been nice.
btw, you can see all the http information for a loaded resource in Chrome, when you open Developer Tools, and select Network. Then click on the file that you want to investigate. (it took me a while to find that)
We had a problems with an iframe wich it's contents was updated by an external javascript routine, the CSS were loaded but were not applied. But updating the body HTML from a routine present in the iframe head worked as suposed to.
This same behaviour was not present in gecko and explorer, but happened the same at Safari browser (webkit)
Hope this could give some light in this curious case.
I would like to add one bit of information that may save some of you some time. It appeared that chrome was not recognizing my CSS either. After reading the above post I reviewed the files in the Developer Tools->Network. Turns out that Chrome was using a locally cached version of my CSS. As soon as I refreshed as opposed to accessing the URL again, it worked!
I'm no expert, but i've made this mistake before, it's rather simple.
You've written:
<link rel="stylesheet" href="/styles/index.css">
If this is a folder in the same directory as your index.html file, then you need to remove the first /. like so:
<link rel="stylesheet" href="styles/index.css">
EDIT: I think someone else mentioned this already, but it may have been overlooked.
I placed my favicon here:
http://www.vittoriosastarsnursery.com/favicon.ico
But for some reason it doesn't want to show in Firefox. It did work in IE, but I'm more concerned about getting it working in Firefox.
Suddenly I found answer here
You should add "?" to your favicon path and it works! Even with path such as images/favicon.ico. Just try:
<link rel="icon" href="/images/favicon.ico?" type="image/x-icon">
Other browsers works too.
Remember to restart mozilla, because of it's own cache, that is not connected with css and other caching.
updated:
Another way is set redirect from favicon.ico to /images/favicon.ico (301 works)
I can see it in Chrome, Firefox, and IE. My friend had a problem like this when we were testing back in college. It was just a weird caching thing that made her think it wasn't working right. I'm sure that everyone besides you will be able to see that it works fine.
Try opening the Dev Tools (CMD + Option + i on Mac) and hard refresh the page (hold the refresh button until options appear).
You could always try restarting your browser after clearing the cache and see if that helps.
<link rel="icon" href="http://khachmeruk.com/favicon.ico" type="image/x-icon">
<link rel="shortcut icon" href="http://khachmeruk.com/favicon.ico" type="image/x-icon">
Two things to consider
If it's working in some browsers and not in others it's likely going to be a cache issue. Clear your cache and refresh, or for more in depth info: How do I force a favicon refresh
If favicon.ico is in the project's root folder but not being recognized by any browsers I would check out the .htaccess, or whatever equivalent of .htaccess depending on server type etc.
For those who suffer from this problem, try move your favicon file to home directory. It worked for me and solved my problem.
https://github.com/ritwickdey/vscode-live-server/issues/77
I was facing this problem with VS-Code live server, as discussed above it's browser cache issue, there is popular github thread on this.
just try the trick:
<link rel="icon" href="favicon.ico?v=2" type="image/x-icon"/>
Happy learning
If you don't want to spend hours. trying to figure out why your favicon is not showing up, make sure to always place it in the root of your project folder and add a link in the <head></head> section of your page like so:
<head>
//other code
<link rel="icon" href="favicon.ico" type="image/x-icon">
//other code
</head>
Folder Structure
--app
-----img
-----js
-----css
-----favicon.ico
It is just a caching issue. Just change the file name and it will show up immediately... otherwise do nothing and it will show up eventually. Browsers are just very persistent with the favicon caching.
It works for me in FireFox. When running identify (part of the ImageMagick package), it reports this problem:
identify: invalid colormap index 'favicon.ico' # error/image.c/SyncImage/3906
Perhaps opening the file in a graphics editor and re-saving it would clean up this error.
I had this problem too. it turns out (for me at least) that blocking users / agents with no referrer via .htaccess caused the problem.
Something that hasn't been mentioned that seems to have been the cause of my issue was the image file size. The image I was using was 4254px X 3850px at 1.3MB. It worked fine in Chrome desktop but not on Chrome mobile or Firefox. Changing the dimensions to 120px X 120px reduced the file size to 9.1KB and the favicon now works well.
P.s. This only works if your code has no issues.
For those who have tried everything and the favicon still does not show up:
Put it in your sites Root Directory
Rename it "favicon.ico"
Make sure your code is like such:
<link rel="icon" href="favicon.ico"/>
IF you still have the same problem, put the whole website in ANOTHER DIRECTORY, like a Memory Stick (that fixed it for me :) ).
REMEMBER: You HAVE to put the icon code in the of EVERY page. :)
Could there be any problems moving favicons and apple touch icons to a subfolder?
Like:
<link rel="shortcut icon" href="/images/favicons/favicon.ico">
<link rel="apple-touch-icon" href="/images/favicons/apple-touch-icon.png">
Yes, some browsers start downloading /favicon.ico at the same time they start downloading HTML document. If there's no file you'll get an extra 404 in your server log and the browser will have to make an extra HTTP request when it recognizes the icon is elsewhere.
A quote from Yahoo's Best Practices for Speeding Up Your Web Site:
The favicon.ico is an image that stays
in the root of your server. It's a
necessary evil because even if you
don't care about it the browser will
still request it, so it's better not
to respond with a 404 Not Found. Also
since it's on the same server, cookies
are sent every time it's requested.
This image also interferes with the
download sequence, for example in IE
when you request extra components in
the onload, the favicon will be
downloaded before these extra
components.
The only problem could be that your relative link is not under the root domain, so that
HOST / YourPath /images/favicon.ico
can be found difficult.
If that would be the case then you would need to include a base href tag in your document and then this would be solved.
p.s. here is the parser i'm writing now to auto download favicons, find yourself in the flow: http://plugins.trac.wordpress.org/browser/wp-favicons/trunk/includes/class-http.php
I am using the following:
<link rel="shortcut icon" href="/images/favicon.ico" />
It is a true 'ico'. When I visit http://mydomain.com, the icon loads. But when I visit the 'www' subdomain: www.mydomain.com...it won't load. Any ideas what is going on?
I found that I had to clear my Firefox cache [CTRL]+[SHIFT]+[DEL], and then restart Firefox before I could see the favicon, which I put in the root of the web server and called favicon.ico.
Note that in recent versions of Firefox the favicon is only displayed on the tab icon and bookmark, not in the address bar icon.
It's part of a bigger firefox bug. If I am in mysite.com and say link rel="shortcut icon" href="/myicon.ico" it works. But this is the only way it works. If am in mysite.com and say link rel="shortcut icon" href="myicon.ico" or any other relative link, it fails. HOWEVER, if I am in www.mysite.com and use relative links, they work fine. Further, if I am in mysite.com and say link rel="shortcut icon" href="http://www.mysite.com/mypath/myicon.ico" it works. Firefox has forgotten how to deal with websites where www.mysite.com IS mysite.com. It used to work, and it doesn't anymore. You can also see that if you flip between www.mysite.com and mysite.com links will change from "visited" to "unvisited" style. FF is broken on this one, and has been for a couple of versions now, though once it worked.
This sounds like a configuration issue on your end which we can't solve without more information. Have you tried using an absolute URL instead of a relative one?
Example:
<link rel="shortcut icon" href="http://mydomain.com/images/favicon.ico" />
This is a result of how Firefox currently handles the caching of the favicon file. To solve you have a few options:
Add GET parameters
You can add an arbitrary GET parameter and value to the end of your favicon URI
(Tip: This trick can be used for any other css/js files when you want to make sure the user's browser is not serving a locally cached version.)
<link rel="shortcut icon" href="/images/favicon.ico?updated=20150818" />
Rename the file
Rename your favicon file and reference the renamed file in your href attribute.
<link rel="shortcut icon" href="/images/favicon_version_2.ico" />
Hard Refresh
A hard refresh may work on some browsers if you are only concerned with updating your local machines favicon. Usually Ctrl+Shift+R or Ctrl+F5 for Windows/*NIX and Command+R or Command+Shift+R on Mac will do the trick.
Explanation: The end result is you need to force the browser to pull a fresh copy of the file instead of using a locally cached file. Adding a ?somevariable=uniquevalue to the end of the file URI tricks your browser into thinking it's dealing with a new file, and new files by nature can't already be cached. The same effect is created when you rename a file.
Extra nerdy technical notes: Using a timestamp, or unique file version number for the GET parameter value is best because it will encourage variable uniqueness. It's possible if the user has already loaded that URI with the exact same GET parameter and value (?updated=20150818 in my example), the browser will not pull a fresh copy, because it may understand it's still dealing with the same file.
The option to cache files based on the GET parameters in a URI is browser specific as the rules are somewhat left up to the browser vendor's to discern between how they handle that particular caching instance (see RFC at http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.9). So, just keep in mind it's possible in some browsers if you are using a date as a value, you may want to include the time as well if you are changing your file multiple times throughout the day.
For security reasons favicons are not used in the address bar anymore starting with firefox 15, but are still used in tabs and bookmarks etc
See http://www.ghacks.net/2012/04/25/mozilla-to-remove-favicons-from-firefox-url-bar/
you can try to put the icon to the root.
For me putting two link refs in the header worked.
FF did not display the icon until the second line was added
<!-- browser icon -->
<link type="image/x-icon" href="/favicon.ico" rel="shortcut icon" >
<link type="image/x-icon" href="/favicon.png" rel="shortcut icon" >
Removing or leaving in the first / made no difference to how FF handled the icon.
The console reported
[Exception... "Favicon at "https://<myhost>/favicon.ico" failed to load:
Forbidden." nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame ::
resource:///modules/FaviconLoader.jsm :: onStopRequest :: line 227" data: no]
But it loaded the .png file anyway, without complaining in the browser window.
Perhaps the first slash in href="/images/favicon.ico" is causing a problem?
Have you tried
<link rel="shortcut icon" href="images/favicon.ico" />
?
What is the directory structure for www subdomain? Can you access other image files using the absolute path?
Fireworks often picks up the favicon.ico file automatically without any code, so long as it is the same folder as the document. Try moving your file up a level to avoid referencing issues.
This problem is annoying...
I usually just add a 16x16 PNG favicon to solve this.
Firefox's way to deal with favicons seems a bit odd and that workaround is, to me, the simplest.
Hope this helps.
Firefox looks for "favicon.png" rather than "favicon.ico" in root folder of your website. I recommend including both for compatibility with more browsers.
The protocol relative URL could be a good option (archived, you never know).
It is about network-path reference (explanation there), try:
<link rel="shortcut icon" href="//images/favicon.ico" />
for firefox you have to use a special tag:
<link rel="image/x-icon" type="image/png" href="/favicon/favicon-196x196.png" />
Now when you drag it to bookmark bar the icon shows.