An idea to stop Firefox being so stupid. (74)

1 Name: Squeeks!!XjdwLWBy 05/02/02(Wed)12:58 ID:Heaven

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.

  • Firefox ONLY grabs or uses favicon.ico IF a HTML/XHTML whatever document that it can read contains the appropriate tag to link to the file. If it cannot find this link, it does not attempt to find it through its own devices.
  • As an extension, instead of replacing it with just 1 default icon, use a range or set of icons that change depending on what MIME type the content in that tab is. This means that themes get extended functionality. So for instance images get their own icon set, or hell, it could be setup so that obscure MIME types even get their own icon, pending on the creators want.

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.

2 Name: !WAHa.06x36 05/02/02(Wed)15:37 ID:jO2jY2IS

> 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?

3 Name: !hcube5iNfc 05/02/02(Wed)17:17 ID:eHgSvpPC

>>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.

4 Name: Sling!myL1/SLing 05/02/02(Wed)19:17 ID:SpQmP4le

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

5 Name: Squeeks!!XjdwLWBy 05/02/02(Wed)20:33 ID:Heaven

>>2

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.

>>4

>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.

6 Name: !WAHa.06x36 05/02/02(Wed)20:44 ID:8opOmpEq

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.

7 Name: !WAHa.06x36 05/02/02(Wed)21:14 ID:8opOmpEq

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.

https://bugzilla.mozilla.org/show_bug.cgi?id=260500

8 Name: !#usr/bin/anon 05/02/02(Wed)21:33 ID:H/G+s6Uc

> 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.

9 Name: !#usr/bin/anon 05/02/03(Thu)16:03 ID:Heaven

> 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.

10 Name: Squeeks!!XjdwLWBy 05/02/03(Thu)23:25 ID:Heaven

>>9

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.

11 Name: !#usr/bin/anon 05/02/04(Fri)04:28 ID:Heaven

>>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.

12 Name: !#usr/bin/anon 05/02/04(Fri)05:56 ID:Heaven

>>11

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" />

13 Name: !WAHa.06x36 05/02/04(Fri)13:22 ID:iR3KFBex

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.

14 Name: Albright!LC/IWhc3yc 05/02/04(Fri)19:27 ID:rIURHPnn

An aside; the .ico format sucks. If you're going to use a favicon, use one in a normal image format please.

15 Name: !#usr/bin/anon 05/02/05(Sat)00:55 ID:Q0Epj+Vc

Nobody said the part after the . has to be an extension

favicon.ico.png with MultiViews = :q:

16 Name: Albright!LC/IWhc3yc 05/02/05(Sat)04:27 ID:Heaven

...what?

No, just favicon.png (or .jpeg or .gif)...

17 Name: !#usr/bin/anon 05/02/05(Sat)05:12 ID:Heaven

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.

18 Name: dmpk2k!hinhT6kz2E 05/02/05(Sat)11:29 ID:C5sDviQ9

Why would you select GIF over PNG?

19 Name: !#usr/bin/anon 05/02/05(Sat)11:29 ID:Heaven

.png

20 Name: !#usr/bin/anon 05/02/05(Sat)11:30 ID:Heaven

>>18

Obviously to have ANIMATED favicos, like on http://rei-ayanami.net/

21 Name: !#usr/bin/anon 05/02/05(Sat)19:34 ID:Heaven

>>20

.mng

22 Name: !#usr/bin/anon 05/02/05(Sat)21:51 ID:Heaven

Does anything support mng yet?

23 Name: dmpk2k!hinhT6kz2E 05/02/05(Sat)22:39 ID:V5JAADjz

>>20
That's plain evil. o.o;

24 Name: Albright!LC/IWhc3yc 05/02/05(Sat)22:59 ID:I5s1R6Iq

>>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.

25 Name: dmpk2k!hinhT6kz2E 05/02/06(Sun)12:14 ID:V5JAADjz

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.

26 Name: hotaru!hoTarufiRE!!Cizp3pu2 05/02/06(Sun)14:03 ID:TZphS0xe

>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)

27 Name: Sling!myL1/SLing 05/02/06(Sun)14:17 ID:ryAPVYec

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.

28 Name: !WAHa.06x36 05/02/06(Sun)15:26 ID:SV6ExeYf

>>24

.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.

29 Name: dmpk2k!hinhT6kz2E 05/02/06(Sun)22:04 ID:aHygNJTN

>>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.

30 Name: Sling!myL1/SLing 05/02/07(Mon)00:03 ID:lzqUEouA

>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".

31 Name: Albright!LC/IWhc3yc 05/02/07(Mon)00:26 ID:B8V3mRyZ

>>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?

32 Name: dmpk2k!hinhT6kz2E 05/02/07(Mon)00:27 ID:aHygNJTN

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.

33 Name: dmpk2k!hinhT6kz2E 05/02/07(Mon)00:40 ID:aHygNJTN

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.

34 Name: !#usr/bin/anon 05/02/07(Mon)04:53 ID:Heaven

>>31
I think >>26 has a point, I've found that saving gif files as png (with the Gimp) usually results in a smaller or equal filesize.
You sure you're not comparing indexed gif with full-color png?

35 Name: Squeeks!!XjdwLWBy 05/02/07(Mon)05:29 ID:Heaven

Wow, what a way to sidetrack a thread. Good work fellas.

36 Name: dmpk2k!hinhT6kz2E 05/02/07(Mon)06:30 ID:aHygNJTN

What's wrong with a discussion meandering?

37 Name: Sling!myL1/SLing 05/02/07(Mon)07:02 ID:lzqUEouA

>>35
Where is the sidetrack? We are still talking about browsers and stuff.

38 Name: Sling!myL1/SLing 05/02/07(Mon)07:05 ID:lzqUEouA

>>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.

39 Name: Sling!myL1/SLing 05/02/07(Mon)07:14 ID:lzqUEouA

>>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?

40 Name: !#usr/bin/anon 05/02/07(Mon)13:46 ID:Heaven

>>3

> [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?

41 Name: bubu!bUBu/A.ra6 05/02/07(Mon)14:15 ID:Nmqwl4jY

>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.

42 Name: dmpk2k!hinhT6kz2E 05/02/07(Mon)23:53 ID:1erAWrmD

>>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.

43 Name: Sling!myL1/SLing 05/02/08(Tue)01:39 ID:1J3VuvHA

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.

44 Name: dmpk2k!hinhT6kz2E 05/02/08(Tue)05:18 ID:1erAWrmD

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?

45 Name: !#usr/bin/anon 05/02/08(Tue)07:56 ID:kSn3g4fh

>>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.

46 Name: Albright!LC/IWhc3yc 05/02/08(Tue)08:07 ID:n0fLp8SP

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.

47 Name: Squeeks!!XjdwLWBy 05/02/08(Tue)10:40 ID:Heaven

>>40

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.

48 Name: Sling!myL1/SLing 05/02/08(Tue)15:30 ID:QLKBu0N2

>>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.

49 Name: hk0!0khonVgaHI 05/02/08(Tue)22:35 ID:2XUjzOBG

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.

50 Name: !#usr/bin/anon 05/02/09(Wed)11:24 ID:Heaven

I use iGrafx Picture Publisher 9 to save PNGs. Worked pretty fine for me so far.

51 Name: !#usr/bin/anon 05/02/09(Wed)22:50 ID:Heaven

>>47
The point was that it's requesting an unreferenced file, so there's a precedent for doing that.

>>1

> 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?

52 Name: Squeeks!!XjdwLWBy 05/02/14(Mon)08:22 ID:Heaven

>>51

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.

53 Name: !WAHa.06x36 05/02/14(Mon)13:18 ID:0NHfuczz

>>52

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.

54 Name: !#usr/bin/anon 05/02/14(Mon)13:48 ID:Heaven

>>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.

55 Name: !#usr/bin/anon 05/02/14(Mon)14:11 ID:Heaven

> webdesigners who try to do fancy thing with favicon.ico

can't they use <link rel> to change it?

56 Name: !#usr/bin/anon 05/02/15(Tue)08:46 ID:HHNIc4ZK

>>52

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?

57 Name: !WAHa.06x36 05/02/15(Tue)13:44 ID:v+iBQ7Ky

>>56

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.

58 Name: !#usr/bin/anon 05/02/15(Tue)16:34 ID:Heaven

>>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.

59 Name: ParadoxHeart!Qxi3DGzQ0Y 2005-04-21 12:13 ID:pYILeRwN

>>43

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.

60 Name: #!usr/bin/anon 2005-04-24 04:09 ID:00ELqJZx

>>59

>the horrible mess that the web was 3 or 4 years ago

"the horrible mess that the web has always been"

Fixed.

61 Name: #!usr/bin/anon 2005-04-27 20:13 ID:Heaven

pwned

62 Name: The Dorkness 2005-06-27 08:12 ID:O0NtWRU4

>>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.

63 Post deleted by moderator.

64 Name: #!usr/bin/anon 2005-07-17 19:01 ID:ulIKrQ1Q

>>62
"...adding checks..."

what now?

65 Name: #!usr/bin/anon 2005-07-17 19:05 ID:ulIKrQ1Q

orz ... s/what now/what/

66 Name: #!usr/bin/anon 2005-08-17 20:21 ID:7/9Y7mAb

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.)

67 Name: #!usr/bin/anon 2005-08-22 00:01 ID:00GCF9AE

>>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.

68 Name: #!usr/bin/anon 2005-10-03 10:51 ID:T9T49A4W

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.

69 Name: #!usr/bin/anon 2005-10-04 00:13 ID:kXLJCWk6

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.)

70 Name: #!usr/bin/anon 2005-10-13 10:21 ID:9Ke3dm+3

Toss in a rewriterule to make it redirect to nothing, thus preventing it from hitting your error logs.

71 Name: #!usr/bin/anon 2005-10-14 05:23 ID:6MLoiK5D

Just modify your webserver not to log image requests. Or if thats too much, just those with extension .ico

Stop whining.

72 Name: dmpk2k!hinhT6kz2E 2005-10-14 06:32 ID:Heaven

Somehow I think senseless requests holding up server processes isn't just whining.

It's trivial, but it's still annoying.

73 Name: #!usr/bin/anon 2005-10-19 01:51 ID:Heaven

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.)

74 Name: #!/usr/bin/anon 2006-01-26 02:36 ID:Heaven

This thread has been closed. You cannot post in this thread any longer.