Ico

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?

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.

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:

Code:

---

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:

Code:

---

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:

Code:

---

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:

Code:

---

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:

Code:

---

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

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.

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.

Quote:

---

Originally Posted by jscheuer1

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.

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