Ico

[bluewalrus]

I can't find where the ico is on this page. http://www.esefdenim.com/ Can anybody else see it in the code? or If its a different extension the icon in the address bar.

[Twey]

'ico'?

It's a Flash movie.

[Snookerman]

'ico'?

It's a Flash movie.
The OP means the favicon.ico icon.

\/ John has the answer

[jscheuer1]

It's in the root:

http://www.esefdenim.com/favicon.ico

If you place an ico file named favicon.ico in the root of your domain, most browsers will display it in the addressbar.

[bluewalrus]

Thanks, I couldn't figure that out, was it in the code?

[Snookerman]

was it in the code?
No, that's the point, if you just put the favourite icon in the root of your domain, it will be displayed even if you don't mention it in the code. If you are wondering how John found it, it's because the favourite icon is always called favicon.ico and he probably just typed it out.


If you place an ico file named favicon.ico in the root of your domain, most browsers will display it in the addressbar.
John, do you know which browsers do that?

[jscheuer1]

Pretty much all modern browsers. IE 6 was a bit balky about it, but IE 7 is much better, though still at times balky. By balky I mean that sometimes the favicon shows up, sometimes it doesn't, and there is no apparent logic to it when that happens. I'm not testing in IE 8 yet, but it should be just fine with it, if you believe the hype about how much more compliant it is/will be. As for the rest, support has been excellent for favicon for quite some time.

[Snookerman]

I just read about the third acid test (http://acid3.acidtests.org/) and one of the criteria for passing is to not show (http://en.wikipedia.org/wiki/Acid3#The_test) the favicon (http://acid3.acidtests.org/favicon.ico) placed in the root. Do you know why that is?

[Twey]

Because it's non-standard, and certainly shouldn't override the page-specified icon.

I wish we could move from that silly .ico format already.

[jscheuer1]

I just skimmed a w3c article How to Add a Favicon to your Site (http://www.w3.org/2005/10/howto-favicon) where they take forever to state in convoluted language that since not everyone has their own domain, not everyone can place a favicon.ico in the root of their domain. They seem to feel that this should mean that no one, not even those with their own domain should be allowed to do so. That's sort of silly if you ask me. As long as there is a standard for those who cannot do it, why shouldn't those who can, be allowed the ease of use that doing so affords?

This question will actually be decided by the folks making the browsers though. And in this case, as with many others, following the w3c recommendation while still allowing for ease of use will probably prevail.

So, ideally, those with their own domains may/should (I'm not deciding this) continue to use the shortcut method of simply placing favicon in the root, while others may use the link rel="ico" tag to override it.

[Twey]

Requiring it to be /favicon.ico is simply daft. Not only does it cause problems for people whose sites are a subdirectory of a domain (and that's not only people who don't own a domain of their own), it also introduces difficulties for those who would rather have a favicon that isn't global to their whole site — to give one area of the site a different favicon from the rest, perhaps, or mayhap they'd rather give each page its own favicon to identify it at a glance (this presumably being the original intention of a 'favourites icon').

[jscheuer1]

Agreed. Did I say anything that wouldn't support those uses? If so, I wasn't being very clear. I just think that in the absence of a link rel="ico" tag, it should default to the /favicon.ext convention if such a file exists. And I believe that many browsers already work this way, and that if some of the current trends in standards compliance extend to this issue, that they will continue to. I hope others will follow.

My point is that it's equally daft to not allow the /favicon.ext convention. We can have either and/or both, can't we?

I think an argument in the past with the /favicon.ext convention may have been that browsers were pulling 404's and wasting time looking for non-existent favicons. I don't think that's much of an issue, it would be like any other missing image, just move on to the next resource.

The only real problems would be - say you have a favicon in the root, but don't want any favicon on certain pages. But then you could simply place the file elsewhere and have link rel="ico" tags for the pages you wish to have the favicon on. And the only one that couldn't be so easily resolved - say you want no favicon, but you are a sub domain of a host that has one in their root. There should be a tag to turn off favicon, perhaps a link rel="ico" tag with no href and perhaps some attribute/keyword to turn it off.

[Twey]

No, I was just airing out my soapbox according to my wont :)

Certainly we can have both, but the goal of a standard is to set the, well, standard, way of doing things — the high target towards which developers should be aiming. So long as they don't interfere with that standard, extra features can be added on to the developers' hearts' content, either for backward compatibility or forward-thinking innovation. If an instance of the latter class is good enough, it may make it into the standard itself one day. However, a standard cannot specify backward-compatibility, or standards would snowball in length indefinitely with each new version :p

Your idea of a explicit favicon-disabling tag is a good one. Have you considered suggesting it to the W3C?

To clarify the issue: the favicon is required to not be displayed in the Acid3 test because the URL, despite returning a valid image, also returns a 404 error code — not because it uses the /favicon.ico URL. The inclusion of this in the Acid3 test could even be considered tacit consent to it.

[Snookerman]

Why don't they just do as they do with the default pages. If there is an index.html file in the folder it is shown. Can't they do that for favourite icons, if there is one in the folder and there isn't one specified in the code, it will show. If the favicon is in the root folder, it should only show on pages in the root folder. That way, if someone has a subdirectory they can just place a favicon in their folder (or link to it) if they want one and not do anything if they don't want one, just like not having an index.html page in the subdirectory will not show the index page from the root (at least I think it doesn't).

[Twey]

I think that the W3C would rather opt-in than opt-out, and these 'magic defaults' that aren't specified in the page or its headers are generally considered a bad thing.

[jscheuer1]

Tongue firmly in cheek:

Many of the W3C recommendations seem intended primarily to have us typing our little digits off. :)

Tongue back in its proper location. (don't ask)

The fact remains that browsers will probably continue to support the /favicon.ext convention (so many pages rely upon it already), and (one would also think, given the W3C's stand on these sorts of matters) they will continue not to favor an opt out tag, as it only encourages the practice they oppose.

So I think we can look forward to a continued mess/confusion as regards /favicon.ext for some time to come.

[Snookerman]

these 'magic defaults' that aren't specified in the page or its headers are generally considered a bad thing.
Do you mean the index.ext or the favourite icons?

[Twey]

The favicons. index.ext is not a magic default at all but a conventional default for a configurable server setting: it has nothing to do with the browser.

[Snookerman]

But wouldn't it be possible to do the same thing with the favourites icon? That it would follow the same rules as the index default.

[Twey]

The favicon path is determined by the browser, not the server, so it can't be adjusted as the other defaults can unless it's indicated to the browser explicitly — via a <link>, for example.

[jscheuer1]

Couldn't a creative server admin like yourself, Twey, set something up in the config, or the .htaccess to deny service of /favicon.ext to any folder other than the root? I know next to nothing about how that might work though.

Couldn't one even direct that a .favicon.ext (or any other file) be served instead?

[Twey]

No — the request for the page and the request for the favicon are two entirely separate requests. There's no state passed between them (except cookies, but that breaks if the browser loads two pages at once).

[jscheuer1]

I was thinking (like):


Redirect 301 /favicon.ico /subfolder/favicon.ico

placed in a .htaccess file in the /subfolder/ directory.

By the way, here's a scary article about favicon:

http://www.w3.org/2006/WSC/wiki/RecommendationDisplayProposals/FavIcon

I had never thought of them in those terms before.

[Twey]

I realise what you were thinking, but there's no way to tell what 'subfolder' is. All the server sees is a request for /favicon.ico; it doesn't know the page for which the browser wants that icon.

With regards to spoofing a secure connection by means of a favourites icon: yes, that's always been a risk, and it's one reason why pages shouldn't really be allowed to affect the chrome at all.

[jscheuer1]

I don't have an environment to test this idea out in. But the page request would occur in a subfolder, so the server could know, at least in theory. But since I have neither the need or availability to try this out, I'll take your word for it.

My thinking, and I may even have misunderstood this much, was that .htaccess, if placed in a subfolder can be in effect for only that subfolder.

[Snookerman]

My thinking, and I may even have misunderstood this much, was that .htaccess, if placed in a subfolder can be in effect for only that subfolder.
I was wondering the same thing after you posted about this before so I did a search and most articles seem to agree with that: the .htaccess file affects only the folder it is in.

[jscheuer1]

I was wondering the same thing after you posted about this before so I did a search and most articles seem to agree with that: the .htaccess file affects only the folder it is in.

Yes, but I think Twey is far more experienced with Apache and .htaccess files. I understand what he is saying, that under that regimen, the request for /favicon.ext is perhaps treated literally regardless as to what is in the .htaccess file.

This would certainly be true if .htaccess can only 301 redirect pages for instance. And there could be other vagaries of the .htaccess interface that would prevent it from working effectively for a resource called from a page, as it may already be cached in the browser. But if it is simply the later, some sort of no-cache, or must renew directive might be able to overcome that.

There could be other considerations. But if this can be worked out, I'm sure many host admins would be interested.

[Twey]

While you can indeed serve /subfolder/favicon.ico for a request to /favicon.ico, it would only work for one specific directory. That is, all requests for /favicon.ico would be redirected to /subfolder/favicon.ico, even if the previous request the user's browser made was for /subfolder2/page.html. This is because the server, at the point at which /favicon.ico is requested, has no idea of the page that told the browser to request /favicon.ico. This is necessarily true, regardless of limitations or lacks thereof of the server in question, because HTTP is a stateless protocol. File requests are entirely independent of one another.

[jscheuer1]

I'm really having trouble following, and I wish I had an environment where I could test this, at the very least it would help me to understand what you are saying. You mean that if there is a .htaccess in /subfolder that is as limited to that folder as is possible to make it, it will affect requests made in other folders?

How about a .htaccess file in all folders redirecting /favicon.ext to .favicon.ext?

[Snookerman]

I don't really understand why having the index.ext page in a folder showing is different from having the favicon.ext show for that folder. When I type in the address http://www.example.com/folder/ the browser should look for files in that folder that are called index.ext, favicon.ext, .htaccess, etc and display/use them.

If the files are not there then nothing should display. If the problem is that the browsers do this in a different way at the moment, then they should think about this for future releases and maybe in a few years there will be no problems. The favicon could be compared to the folder.jpg that shows as the default folder thumbnail in Windows. I'm sure I'm overlooking and misinterpreting things but I'm sure you get my idea.

[jscheuer1]

Actually it is the server's configuration which determines whether or not to serve index.ext in any given folder if it has one when no file is specified. And it is the server config that determines what do if there isn't one. It can just show the directory listing, or a permission denied, or a file not found. It all depends upon the server's config, the browser has little to do with it, all the browser does is request the folder.

The /favicon.ext is another matter. The browser (if so programmed, as most are these days) actually requests that specific file.

Now are you beginning to see the difference?

[Snookerman]

Well I don't know much about servers since I've only had websites on web hotels so I haven't done much except turning PHP5 on and copying and pasting some code into the .htaccess files (if that even counts as server settings). Wouldn't it be possible for the server to do the same thing it does to the index page but with the favicon when the user goes to a folder on the site? I mean, they are pretty much the same thing, two files, one of which shows in the browser window and the other a bit above in a smaller "window"/area. And about the browsers requesting the favicon image, well if W3 decided to do it this way maybe the browsers would change and FF5, Opera 11 and IE15 (cause they're slow) would adapt to that.

[Twey]

I've been trying to describe this in generalities to keep it clear, but perhaps it would make more sense explained in terms of HTTP requests.

OK, so: say that there are two pages, http://www.example.com/dir1/page1.html and http://www.example.com/dir2/page2.html. The browser requests the first page:
GET /dir1/page1.html HTTP/1.1
Host: www.example.com

... and the server sends it back. Then, the browser wants a favicon for the page, so it makes another request using the magic default URL for favicons:
GET /favicon.ico HTTP/1.1
Host: www.example.com

No information is sent in the request for the favicon that identifies the page for which the icon is intended. So, the server can redirect all requests for /favicon.ico to /dir1/favicon.ico, but the problem is that the request for a favicon for /dir2/page2.html looks exactly the same to the server as the request for a favicon for /dir1/page1.html:
GET /favicon.ico HTTP/1.1
Host: www.example.com

What we could do is require browsers to send the page for which we're requesting a favicon as a GET parameter, or through some other avenue:
GET /favicon.ico?url=http%3a%2f%2fwww%2eexample%2ecom%2fdir2%2fpage2%2ehtml
Host: example.com

... so that the server can distinguish them and perhaps send an appropriate icon for the page (based on what subdirectory the page is in or on other information). Alternatively, we could add a field to HTTP to associate an icon URL with the page, so the response looks like:
HTTP 200 OK
Content-Type: text/html
Icon-File: /dir1/favicon.ico

... content ...However, this approach offers no benefits over encoding the icon in the HTML document with a <link> tag, as we currently do and as is recommended by the W3C, and offers another opportunity for newbie webmasters to trip up (they seem to have difficulties with HTTP headers).

Snookerman, you're making some fairly seriously erroneous assumptions. Firstly, that the browser can look in a 'folder'. The browser cannot scan a directory. There's no guarantee that an HTTP URL will even be associated with a directory; the browser sends the server a string, and the server sends back some headers and data. That data might not come from a file at all; it could be generated on the fly. It just happens to be convenient, when serving static files, to map URLs to actual files on the filesystem, using / as a directory separator.
Secondly, that the browser ever knows about these files. This is where /favicon.ico differs from the rest: the icon is needed by the browser, so the browser is responsible for finding and handling it. In the case of .htaccess and index.*, it's all about the server: .htaccess tells the server how to handle requests in this directory where different from requests in the directory above, and index.* tells the server what to do when the directory is requested, but no file is specified. They don't have to be named like that; the server can be configured to use whatever filenames for those files it likes, since the browser need never see them (in fact, in the case of .htaccess files, the browser is generally denied access to them, since they may contain sensitive information).

[Snookerman]

Like I said, I don't know much about servers and I appreciate your help, I'm learning a lot. So here is my question: why is it not possible to make the settings for the favicon on the server side and remove the responsibility of the browser to find the favicon. If I understand this correctly, when the browser requests something by sending an address (e.g. http://www.example.com/folder/), the server decides what to send back and the browser interprets that and shows something. Now why can't the server decide what favicon to send back so the browser will show it in the little icon area? I guess I'm seeing the little area up there kind of like a second window.

[jscheuer1]

Now you're just going in circles, Snookerman. You are asking the same question in a different way, hoping for a different answer. The fact remains as Twey has now so well described, that in the current state of affairs, when a browser requests /favicon.ext, the server has no idea what page it is for, let alone what folder that page is in.

[Snookerman]

in the current state of affairs, when a browser requests /favicon.ext, the server has no idea what page it is for, let alone what folder that page is in.
I never talked about the current state, I was talking about the future, a future where the browser doesn't request the favicon.

[Twey]

I did cover that point in my post, in fact.