Posted by J.O. Aho on 09/24/06 18:11

d43m0n AT shaw DOT ca wrote:
> J.O. Aho wrote:
>> The Eclectic Electric wrote:
>>
>>> To be honest, it was someone else's idea to interrogate the accept header
>>> and I'm not sure whether his or my interpretation of how HTTP works is
>>> correct (probably his!). He was implying that the browser sends up
>>> individual HTTP requests for each element of the page, which would mean it
>>> should indeed be possible to catch whether or not it was possible to send a
>>> gif for the favicon.
>> If my mind don't fool me, even a system that don't gif would request the gif
>> file if it's linked from the html and it's first locally at the client that
>> you will know if the gif was displayed or not, the browser won't send a
>> special "header" telling the web server what it's capable of doing.

> Ok, it looks like I have to spill it out for you.

I think you may need to read a bit slower so you won't miss things...


> First, by default, Internet Explorer will request for a favicon.ico in
> the root of the web directory, or atleast at the root of the url. For
> instence, "http://google.ca/favicon.ico".
>
> Now, HTML code will redirect the browser to where the favicon is,
> either relitive or absolute location.
>
> <LINK REL="SHORTCUT ICON"
> HREF="protocol://domain.ext/directory/mypage.ico">
>
> Now, if you wanted to know that, this was the wrong group to post your
> question in. However, to take it the step further, you could make that
> ico to php. As long as the return data is binary/base64, it will use it
> for the image. Now we all should know that fread is binary safe, so we
> have no worry about that.

As I pointed out before, the browser won't tell the web server what it can and
can't, you need to keep track of browsers in your php code and match the
current clients version to your list to know what is the most advanced it can
handle in favorite icons.


//Aho

[Back to original message]