Although Firefox is a great browser that protects users from pop-ups, spyware and should replace IE it does have a big issue.
favicon.ico
Firefox by default wont find favicon.ico by reading a HTML/XHTML document and looking for a <link rel> pointing towards it, instead it will play a guessing game and think that its located in the same folder as the document being requested. The result? My error log files are getting too fucking built up with firefox browsers crawling for a file that isnt there. Now at first thats not a big problem, but when my weekly log files show 250,000 requests average, the 404 error requests for favicon.ico are a bit too much, especially when im checking logs for REAL errors.
So, here is my solution.
The result? Not a significant reduction with user interaction, but it saves site admins like me having to cull out favicon 404 errors. I should not have to have an ico file in EVERY FOLDER, or clean out my error logs constantly as a result of letting firefox users view my sites.
Anyone got thoughts about this? If I get around to it, I may just suggest this to Mozilla or someone who cares.
> Firefox by default wont find favicon.ico by reading a HTML/XHTML document and looking for a <link rel> pointing towards it
Are you sure? I was under the impression that if you have a <link> tag to the favicon, this would be used an no other accesses made. Furthermore, I know the favicon is quite aggressively cached, so that if you change your favicon, it's very hard to get Firefox to reload it - shift-reload won't help, for instance. A cache clear might be required before it reads the new one.
I've heard a lot more complaints about IE looking for favicon files, on the other hand.
Of course, I haven't done any real tests of any of this. Anyone else have some hard information?
>>1
signed. I'm disgusted that the Firefox devs copied IE's behavior and will GET /favicon.ico without being told there is one. I had 1516 requests for favicon.ico on my rinky dink little site by Firefox users last month and I neither have one nor specify anything in <link>. I would expect Firefox will honor a different file if one is specified, but that's no excuse for making an unwarranted request if one isn't.
I rather hate the favicon implementation as a whole.
For the user, how to disable favicons:
about:config
browser.chrome.favicons -> false
For the webmaster:
put a favicon.ico in the / directory and your logs will be clean
For the one behind the stupid idea (not the icon, the seeking instead of using only LINK REL= HREF=):
MS + IE
icons are cached yes, and on bookmarks the icon imagedata itself is part of the URL. Export your bookmarks and look at the "ICONDATA" value. This doesnt solve the problem, it just reduces it somewhat. Firefox also complies to "no-cache" meta tags, which can also be a problem for this issue.
>put a favicon.ico in the / directory and your logs will be clean
INCORRECT~!
Take a look at this line from my error log:
[Sun Jan 30 06:41:57 2005] [error] [client 65.214.#.#] File does not exist: /srv/http/4-ch.net/www/politics/favicon.ico
The browser was trying to reach http://4-ch.net/politics/favicon.ico (404) and not http://4-ch.net/favicon.ico (200). It was also identified as Firefox 1.0, on Windows 2000.
I SHOULD NOT have to shove a single file into every bloody folder just to prevent a browser that shouldn't be doing something from bloating my error logs. That's nearly 60 copies of the same file I have to have.
That does seem like some sort of bug, as there is no reason for this behaviour. It's not copying IE, since IE only looks at the site root, and nobody would be expecting a browser to find a favicon in any old directory.
This appears to be the Bugzilla entry for this, which kind of seems to be filled with zealots and other hotheads, which isn't exactly helping.
> In any case, I've redirected /favicon.ico on the main site to
www.mozilla.com/favicon.ico, as it won't have the negative effect I was afraid it would (I was assuming all those 39,000 /favicon.ico hits I got yesterday would be directed; fortunately, this bug doesn't cause re-tries if Firefox gets the icon).
I'm Anonymous and I approve this solution.
> use a range or set of icons that change depending on what MIME type the content in that tab is
Most of them will be html or xhtml, though. Hmm... for those, you could do something like: use the domain name as a seed to pick a colour. (either choose from a fairly large set of different-coloured icons, or tint a generic icon)
So all pages on a specific domain should have the same coloured icon, and will be more or less distinguishable from whatever else you're viewing. If a site doesn't want to be mud-brown or pink or whatever they can always make a custom one.
I figured that using them by the mime type would be better because it allows users to see what kind of file is open on the specific tab they want to see. Making it use dynamic or random colours could be something as an added bonus. I dont see any gain from using it by default.
>>10
Part of the argument for aggressively using favicons seems to be that they enable the user to easily identify which tabs belong to which website. It was based on that idea.
Mime types could be useful, but I still think people will be viewing more html documents than anything else.
But if the HTML documents have their favicon.ico's linked in them, there is no problem. Browsers should not be attempting to request something without a link inside a document pointing it that way, or unless the user requested it.
Look, its 1 line of code:
<link rel="shortcut icon" href="http://the.url.to/favicon.ico" />This is really two separate issues. Or three, depending on how you count.
First, a bug: Firefox digs around for a favicon even if one is supplied in a <link> tag. That's obviously wrong, but is simple to fix.
Second, an opinion: loading a favicon if none is specified. Some people seem to oppose this on principle, but that seems unnecessarily dogmatic. It may not be in any official standards, but it is a de facto standard, so you might as well do it, because the users benefit.
Third, a bad behabiour: Firefox keeps requesting the favicon on each page hit if one doesn't exist. This is obviously a side effect of the cache implementation: a 404 is not cached. This makes sense for normal pages, but the favicon handling should be changed to rememeber 404s and not keep re-requesting.
An aside; the .ico format sucks. If you're going to use a favicon, use one in a normal image format please.
Nobody said the part after the . has to be an extension
favicon.ico.png with MultiViews = :q:
...what?
No, just favicon.png (or .jpeg or .gif)...
I think using .ico is fine. It's a format that isnt bloated, and for a 16x16 image, serves the purpose well. I think if any other format would be used, GIF would be 2nd place.
Why would you select GIF over PNG?
.png
Obviously to have ANIMATED favicos, like on http://rei-ayanami.net/
.mng
Does anything support mng yet?
>>17: But it's a bitmap format with no compression, and, if I recall correctly, it limits you to only sixteen or so colors...
>>18: Often I'm able to make a smaller GIF than a PNG out of the same image. It might be because PNG is cramming in more metadata, or maybe The GIMP's PNG compressor just sucks.
>>20: That wasn't animated in Safari, but when I tried in Firefox... Good gravy, that's one for the feature request (un-request?) pile.
>>22: I believe Moz used to, but the feature was removed. So, no, no major browser currently does.
Deflate is generally better than LZW, so for most images PNG will be smaller unless you hit a corner case. I believe GIMP has a decent compressor, but I'm not certain.
Mind you, you're right about PNG overhead. IIRC, a single-pixel GIF is 31 bytes, while the same PNG would be 60-70 bytes. So maybe GIF would be a better choice for something so small after all.
Can anyone comment on MNG? It sounded good, but I heard somewhere it turned into a huge hairball.
>Often I'm able to make a smaller GIF than a PNG out of the same image. It might be because PNG is cramming in more metadata, or maybe The GIMP's PNG compressor just sucks.
or perhaps you're not converting the image to indexed mode (Image > Mode > Indexed...) before saving it?
same image (320x320, random data):
test.png: 101 KB (103,993 bytes)
test.gif: 137 KB (141,195 bytes)
My opinion: too little too late too big too featureless.
What people wanted was a quick replacement for GIF. They got a bunch of monsters instead. PNG. MNG. JNG. Alpha transparency. 32-bit. Who wanted all that?
"At the time of this writing (1997), the MNG specification has undergone some 31 drafts--almost entirely written by Glenn Randers-Pehrson--and seems fairly close to being frozen" www.libpng.org/pub/png/pnghist.html
I remember back then trying to convince Glenn to add .ECC features like a script (only one pic stored and it could be played several times) but he didn't want to make MNG too complex. Well, maybe he was right, but...
Meanwhile no working MNG creation library in sight for years. PaintShopPro was the first to come out with a working model, but the files, being 24/32 bits, were huge. No way this could go on the internet. And basically only PSP could read those MNGs. Other MNG players would have limited degrees of success playing these back.
The main failure of MNG IMO is that it didn't take bandwidth in account. No real effort was made to save space. And back in the day, playing back images at 24bit was SLOW.
There should have been a MNG8, a direct clone of GIF with just the LZW replaced. But no, they had to make it "perfect". That alpha crap may be perfect but in practice it's a pain. Browsers had a hard time with it, and probably still have. Currently it's basically only used at 2chan to play pranks with PNGs, a pic of a pretty girl thumbnail becomes another pic when viewed in full. Whee.
Meanwhile, the patent on GIF expired. Bye bye MNG.
.ico supports 24 bit colour just fine. Also, for a 16x16 image, compression really isn't very important these days. We're talking 1kb files. This is an order of magnitude less than your average index.html.
Of course, using standard formats is a better idea in general, but since the <link> format for favicons doesn't care what format the favicon is in or what its name is, it's a moot point. Reading /favicon.ico is a backwards-compatibility kludge anyway, so it's not like anyone's going to do any work to improve it.
>>27
I did a bit of reading, and it seems they're now playing with APNG, essentially a quick hack on PNG that gives animation much akin to GIF. Supports an actual alpha channel too. My only regret is it doesn't support compression of deltas between frames.
Pity about MNG. There were some neat tricks in there.
>APNG
Looks interesting. But not yet what I had in mind, the possibility of reusing older frames.
DISPOSE_PREVIOUS seems interesting. There was something I wanted from GIF, Background/Sprite Frame Flags. The Background frame would be always be redrawn, and Sprite frames playing over it. Maybe DISPOSE_PREVIOUS can do that, by always reverting the scene to the previous one. Tho, the first frame would be an empty background... it would end up blinking. No good.
My Background Frame Flag would have been "don't display this frame until the next".
>>27: I love PNG's alpha channel capabilities, as well ad the 32-bit-ness (if I need it). They're just kind of hard to work with sometimes because fucking Internet Fucktard Assplorer, which is very gay, breaks it.
>>26: Could you post the test image in question somewhere in an uncompressed format (BMP or TIFF)? What program did you use in your test?
MNG supported objects like that. APNG is more or less a PNG counterpart to GIF's animation, and only a little less limited.
One problem with the spec is it doesn't clearly specify behaviour between frames. Ie, DISPOSE_PREVIOUS could work just fine if the decoder only diplayed finalized frames. I suspect in this case that what you want to do is actually possible, and was intended. There isn't that much use for a DISPOSE_PREVIOUS flag otherwise.
I concur with >>31 (and I also curse IE under my breath).
What I'd enjoy having is an image format that allows some parts to be lossless and others to be lossy. Ie, cut an image into 16x16 blocks, passing some blocks off to jpeg and the rest to png, possibly throwing in a lossless alpha channel on top.
I heard somewhere once that it might be possible to combine JBIG and JPEG in such a way, minus the alpha channel, but I have my doubts.
Wow, what a way to sidetrack a thread. Good work fellas.
What's wrong with a discussion meandering?
>>35
Where is the sidetrack? We are still talking about browsers and stuff.
>>34
It depends on the content of the image.
Sometimes GIF wins, sometimes it's PNG.
If the image had uniform, gradient colors, PNG wins.
>>31
There has been a lot of broken implementations.
I recall Quicktime taking over the .PNG extension in all my browsers without asking me, and no way out. No uninstall. Problem was, QT version of PNG was broken in more ways than one. That's when I swore to never install Quicktime ever again.
Then, I seem to recall it took a while before Netscape caught on. Is it flawless now? And the others? Does it work under Opera?
> [Firefox] will GET /favicon.ico without being told there is one.
Download managers and spiders will look for robots.txt, isn't it similar to that?
>I recall Quicktime taking over the .PNG extension in all my browsers without asking me, and no way out. No uninstall. Problem was, QT version of PNG was broken in more ways than one. That's when I swore to never install Quicktime ever again.
A late relief for QT-related PNG / MP3 (another common victim of QT) disasters is throwing out all mime-type associations in the "browser plug-in" tab, and then doing the same in the "file type association" tab ON INSTALL.
>>39
It's worked flawlessly in Opera from at least 6.03. Perhaps even longer, I can't recall. It did work in some form from 3.0 on.
Going back, PNG has worked properly in ACDSee since at least 1997 too. I'd be surprised if it didn't work properly in most implementations. Well, except for IE, which by default has somewhat broken alpha.
There has been also discrepancies between image editors.
A PNG in Photoshop looked different than the same image in PSP. Something to do with PSP never showing the alpha and PS showing it always. PNGs created by PS were bloated so I always had to resave them under PSP, that's where I noticed it.
Amusing (or maybe not so amusing) fact: Painter never supported the PNG format.
And PSP always stripped out the alpha when saving, I believe. That washed-out look was always gone after a resave.
Three image editors, three broken PNG support.
I loved PNG for its compact size but I never got to use its alpha.
Ah. I have a pet peeve with Adobe's products in that regard. You'd expect that the world's premier raster/vector/layout/etc editors would flawlessly handle images they support. Hah, how naive of me!
Whenever I save a PNG in PS I always have to crush it. I've found advpng to be better than pngcrush in general, but both preserve alpha. Generally I get about 20% savings over PS.
The visual differences you were noticing though, are you sure that wasn't due to color profiles and gamma?
>>40
robots.txt usually apply for the whole site so a single request by a bot is all there is at. Bot also usually don't pound the server with requests for robots.txt for a short period of time.
Here is a ridiculously-exhaustive list of browsers that support PNG, and the level to which they do so: (Did you know the Dreamcast browser supports the PNG alpha channel better than IE does?)
http://www.libpng.org/pub/png/pngapbr.html
Lists of other programs (image editors and others) that support PNG can be found through the links at the bottom of that page.
>>34: I may have forgot to convert the image to indexed color. To tell the truth, it's been a while since I tried. I'll be sure to keep it in mind when I try it in the future.
robots.txt is exactly for that, crawlers like Googlebot. Its not designed for end-users' software to get a "ruling" on where, and where not to go. It's to prevent web spiders trying to dig around in links where webmasters would prefer not a search engine to find out.
>>44
Yeah - Adobe bad boy.
Looking at PS from the link Albright provided, I see that it's even worse than I imagined.
I used to use pngcrush, but PSP v5 has a pretty good compression level already. Dunno about later PSPs - I don't like the new design - but I suppose it's as good. I'm not going to bother using a command line for a couple of 100k on a very large image.
Ah yeah, maybe it was gamma. I never use that gamma stuff either anyway.
Quick note about PNG files and why saving them sucks in Photoshop, PSP, etc.
Gimp, and lots of other free software tools (including Moz/Firefox) all use the libpng library. It is the reference implementation. GIMP I think does some pngcrush-like tricks before saving too. (pngcrush uses libpng too, it just knows how to use it the best)
Meanwhile Photoshop, IE, PSP and the others all have native implementations which function at different levels of compatibility and are just a bit less sophisticated. Because PNG isn't quite as popular, they've settled for "at least it works so we can list it on the box" functionality.
And it's unfortunate that the gamma chunk is actually interpreted by the browser when you can't also set the gamma for any other part of a page.
You could always omit the gamma chunk if you feel it will mess up your color matching.
I use iGrafx Picture Publisher 9 to save PNGs. Worked pretty fine for me so far.
>>47
The point was that it's requesting an unreferenced file, so there's a precedent for doing that.
> I should not have to have an ico file in EVERY FOLDER
Hmm. True. Maybe in addition to the first and third points in >>13:
If no icon is specified by <link>, Firefox should only look for favicon.ico in the top directory of the domain.
Is that an appropriate compromise?
Apologies for the late reply. I feel a browser should not be "looking" for a file unless it was linked to it through the HTML (ie <img>, <link rel> etc etc) or if the user requested it. That's the way I feel a browser should operate, and webmasters shouldnt have to insert any file into one or every folder just to satisfy the demands of one browser. If the designer doesnt provide an icon, for whatever reason (and this reason could be more than "dont care"), a browser shouldnt have to poke around trying to find something that is not suppose to be used.
Another compromise would be BETTER CACHING of icons for a site. However that leads to other problems when you have multiple pages with different icons on the same site.
The caching is, as I've mentioned, very aggressive, and you have to go to great lengths to get Firefox to re-read a changed favicon. HOWEVER, there is no caching for non-existent icons, which is the real problem here. Nobody would be complaining if Firefox just checked for the icon once, and then didn't check again for a few weeks.
>>53 Admins wouldnt complain because the number of favicon.ico requests would be low, but the webdesigners who try to do fancy thing with favicon.ico will. But boo-hoo to that.
> webdesigners who try to do fancy thing with favicon.ico
can't they use <link rel> to change it?
Signed.
Except, I don't think there should be a compromise: if the HTML doesn't reference it, why the fuck are you GET'ing it?
Why are you treating data communications protocols as some sort of religious dogma? You get it because it's convenient to the users and the web designers. That's it. There's no divine law that says that a file has to be referenced in a HTML document before you can get try to access it.
>>56
It doesn't look like it's going to be disabled, and it does have some use. Best you can hope for is that it behaves politely.
Paint Shop Pro has handled PNG alpha transparency since at least version 6 or 7. When you initially load a PNG into it, it does not load the alpha channel. If you want the alpha then load it into a mask. Also, by default, PSP is configured to save PNGs without an alpha channel. Choose options when saving to PNG and then run the optomiser. From here you can switch on saving of transparency to the alpha channel. The settings in the optomiser should be retained for the next time you save a PNG.
It's not as nice as it could be, but it works.
Going back to the original topic. I don't like that it gets favicon.ico without being asked to, but I suppose it is the only way to display icons for files that cannot link to it, such as images. It is however, very bad form that they don't cache the 404. Worse still is the fact that they still look for it even when an alternative has been specified in the document that was requested. That is undeniably a bug because no one needs more than one icon.
Personally I'm inclined to say that it should look for the favicon.ico only for files that cannot contain links to it. For an HTML document that does not contain a link, it should not look. Web developers should not be allowed to be lazy or what you end up with is the horrible mess that the web was 3 or 4 years ago, and is still recovering from.
>the horrible mess that the web was 3 or 4 years ago
"the horrible mess that the web has always been"
Fixed.
pwned
>>52
The problem with this is that icons for things like bookmarks won't be able to be displayed unless their data is retrieved. Yet a user at http://example.org/~bob/hosted/www.site.com/me/ won't want example.org's root favicon.ico loading for his page, so he puts it in every directory he wants it to apply to. He couldn't just put it at the root of his site because the browser wouldn't be able to tell at which directory the parent site stops and his site starts. The difference between IE and Mozilla/Firefox in this regard is that the open-source nature of Moz. allowed web designers to scratch this itch by adding checks for this.
orz ... s/what now/what/
One solution is to use Gimp to draw up a quick 16x16 image and save it as favicon.ico (gimp 2 can save winders icons).
Then, create a symlink to /web-root/favicon.ico in all the subdirectories. Since the symlink and target file will both be within the Web tree, any server ought to return the same favicon to everyone. (This of course assumes you're using a Unix or Linux server. I don't know if it's even possible on a Windows server.)
>>66
In NTFS, you can create hard links for files and symbolic links for directories and drives, and there may be a way to do symbolic linking of files in Apache.
Does firefox cache 301 (moved permanently)? If so, you could config apache to just return 301 (to /favicon.ico, or to mozilla.org/favicon.ico or whatever floats your boat) for any files called favicon.ico, anywhere in your heirarchy.
How about a cache of favicons that distinguishes between "have not checked" and "checked, but not found"? The first time you look in the cache for arr.com, you will get "have not checked", so you look, find nothing, update the cache. The next time you visit a page on the site, you hit the cache for "nothing there", so you don't check again for some long period of time. (Hmm, I like that solution. Maybe some day I'll be motivated enough to try coding it - I use Galeon.)
Toss in a rewriterule to make it redirect to nothing, thus preventing it from hitting your error logs.
Just modify your webserver not to log image requests. Or if thats too much, just those with extension .ico
Stop whining.
Somehow I think senseless requests holding up server processes isn't just whining.
It's trivial, but it's still annoying.
It's also a waste of bandwidth. Assume there are 70 million firefox users, and they each visit 3 domains without favicons a day. 210 million requests (say 70 bytes with HTTP 1.1), 210 million 404s. Call the 404 response 300 bytes on average (though some hosts will generate larger). 210M * 70 + 210M * 500 is about 80GB a day. Not huge in terms of total Internet traffic, but come on.
(How big is the average 404 message? Apache defaults generate about 300 bytes. IIS' default 404 is more like 1600. Still, more hosts probably generate smaller 404s than larger.)
This was fixed, apparently.