>> Quick question about Favicons

On Tue, 20 Jul 2004, Els wrote:

That's what I mean by IE not obeying the headers the server
gives. IE accepts what you say in the <link>,

That's a leap of faith, I must say. According to the notorious
"moniker" page, IE on principle disbelieves any MIME type information
for a whole raft of types where it thinks it can do a better job by
itself.

Are you sure it's believing what what it was told? Or is it just that
the <link> happens to be telling it something that it had deduced for
itself already?

which is the correct type for an icon.

Uh-uh; but that's not the correct way to specify the MIME type for an
RFC2616-conforming HTTP client (just in case anyone had missed that
point!).

Alan J. Flavell wrote:

On Tue, 20 Jul 2004, Els wrote:

That's what I mean by IE not obeying the headers the
server gives. IE accepts what you say in the <link>,

That's a leap of faith, I must say. According to the
notorious "moniker" page, IE on principle disbelieves any
MIME type information for a whole raft of types where it
thinks it can do a better job by itself.

Are you sure it's believing what what it was told? Or is
it just that the <link> happens to be telling it something
that it had deduced for itself already?

Ehm I was sure it didn't obey the header, I just figured
(leapt in faith as you will ;-)) it obeyed the <link>. Figured
wrong I see.

which is the correct type for an icon.

Uh-uh; but that's not the correct way to specify the MIME
type for an RFC2616-conforming HTTP client (just in case
anyone had missed that point!).

Now you confused me. What is an RFC2626-confirming HTTP
client, and what would be the correct way of specifying the
MIME type for it? Or you mean that the type attribute in the
<link> isn't the correct way? In that case I'm not as confused
:-)

--
Els http://locusmeus.com/
Sonhos vem. Sonhos vão. O resto é imperfeito.
- Renato Russo -
Now playing: New Kids On The Block - Tonight

Els <els.aNOSPAM (AT) tiscali (DOT) nl> wrote

Then if I type in http://webdev.ucop.edu/tltc_ph2/favicon.ico
I don't get to see an icon either. Just a line of strange
characters in Firebird, and a blank page in Opera.. Did you
really make an icon, or just changed the name of a jpg or bmp
to ico?

It's being served as MIME type text/plain, which is why the browser
tries to render it as plain text.

--
Dan

On Tue, 20 Jul 2004, Els wrote:

Ehm I was sure it didn't obey the header, I just figured
(leapt in faith as you will ;-)) it obeyed the <link>. Figured
wrong I see.

I'm not sure. I was asking the question.

Uh-uh; but that's not the correct way to specify the MIME
type for an RFC2616-conforming HTTP client (just in case
anyone had missed that point!).

Now you confused me. What is an RFC2626-confirming HTTP
client,

RFC2616 is the HTTP/1.1 protocol specification. It says that whenever
there is a server-provided MIME type then that is authoritiative; only
if that is not available shall other sources of MIME type information
be considered.

Thus, applying the principle to this case, if the server says
text/plain and the <link> tag says image/x-icon, then according to
RFC2616 the authoritative type is text/plain (meaning, presumably,
that it cannot be used as an icon). My understanding is that this
general rule was made for security reasons.

MSIE on the other hand (in its current implementation, prior to
Windows/XP SP2) thinks it knows better than to follow the mandatory
Internet specifications, and, for quite a range of content types,
goes and makes its own evaluation of the content...

Background reading at
http://ppewww.ph.gla.ac.uk/~flavell/...tent-type.html

It's claimed that as of XP SP2 they are going to tighten up on this
for security reasons and by implication, head somewhat in the general
direction of conforming with the requirements of the specification);
but reports from someone who's trying the SP2 beta/prerelease/
whatever-it's-called are somewhat confusing - it does not seem to
behave in the way that the documentation said it would. So I'm
reserving judgment for now, and haven't written that up in the above
page yet.

and what would be the correct way of specifying the
MIME type for it?

For HTTP resources there's no doubt: the *server* SHOULD[1] send the
correct MIME type. And if the server does what it SHOULD, then the
client MUST accept it (or reject the resource as defective/unusable) -
that's a security feature.

Or you mean that the type attribute in the
link> isn't the correct way?

No, I'm saying it just happens to have the correct value, but I'm
doubtful that IE (which breaks the rules) is paying any attention to
it, and I *know* that specification-conforming software *must* ignore
it, since they got a MIME type from the server.

My hunch is that IE looks inside the data and works out for itself
that it's an icon, irrespective of what the HTTP server and the <link
type=...> attribute said. But feel free to prove me wrong, it's
happened often enough before ;-)

all the best

[1] SHOULD and MUST are technical terms in an RFC, and have a rather
precise meaning. Which is also defined in an RFC ;-)

Alan J. Flavell wrote:

[snip a lot of useful information]

[1] SHOULD and MUST are technical terms in an RFC, and have
a rather precise meaning. Which is also defined in an RFC
;-)

Aaarggh!
I'm gonna ban the word RFC from my brain :-)

--
Els http://locusmeus.com/
Sonhos vem. Sonhos vão. O resto é imperfeito.
- Renato Russo -
Now playing: Bow Wow Wow - Do You Wanna Hold Me

Brian wrote:

Els wrote:

Brian wrote:

Els wrote:

your server is giving text/plain, whereas my own favicon
is served as image/x-icon.

IE obeys the type you give in the <link

Does it? Or are you guessing? I don't have an icon
creating utility, so I can't test this myself.

It's got nothing to do with the icon creating utility.

I didn't mean to imply that it was related to the utility,
only that I could not create an icon and then test it in IE
using various mime types.

Ah, right. If you feel like testing it, feel free to use my
icon (or any other icon, I'm sure noone would mind).

I just checked the headers with Lynx, and your server

It's not my server; I'm not the op.

Sorry, I see that now.

is serving the icon as text/plain.

That doesn't answer my question.

Understood.

IE accepts what you say in the <link>, which is the
correct type for an icon.

Does it accept what you say in the <link> attribute? Or
does it sniff the contents and guess at content type? IE
has a list of content types that its programmers regard as
unreliable; chief among these is text/plain. In the case of
a css file whose mime type is text/plain, MSIE/Win will
sniff it and treat it as text/css. It doesn't matter what
the http headers say, nor what the <link> claims it is.
You're telling us that IE treats <LINK type="image/x-icon"
...> differently then it treats <LINK type="text/css"...>.
I'm skeptical.

With good right, as you can read in my reply to Alan an hour
and a half ago :-)

--
Els http://locusmeus.com/
Sonhos vem. Sonhos vão. O resto é imperfeito.
- Renato Russo -
Now playing: Counting Crows - Mr. Jones

Brian <usenet3 (AT) julietremblay (DOT) com.invalid> wrote in
news:10fqputkgoc4017 (AT) corp (DOT) supernews.com:

Els wrote:

your server is giving text/plain, whereas my own favicon is served
as image/x-icon.

IE obeys the type you give in the <link

Does it? Or are you guessing? I don't have an icon creating utility,
so I can't test this myself.

If you are using a PC, IrfanView is free, and will create
Windows icon(ICO) files:
http://www.irfanview.com/

--
Dave Patton
Canadian Coordinator, Degree Confluence Project
http://www.confluence.org/
My website: http://members.shaw.ca/davepatton/

On Tue, 20 Jul 2004, Els wrote:

and what would be the correct way of specifying the
MIME type for it?

"Alan J. Flavell" <flavell (AT) ph (DOT) gla.ac.uk> posted:

For HTTP resources there's no doubt: the *server* SHOULD[1] send the
correct MIME type. And if the server does what it SHOULD, then the
client MUST accept it (or reject the resource as defective/unusable) -
that's a security feature.

Although, in this case, there is no "correct" MIME type. There's an
experimental one, but no registered one.

I've been playing with favicons on a local server and getting all sorts of
unpredictable behaviours with different webclients. Various browsers will
accept me making a <rel="shortcut icon" ....> link to icon or PNG files,
and most will automatically use an unlinked to "/favicon.ico" file. MSIE
was actually the worst at it. I had to bookmark, reload, drag the icon
about, etc., before it'd use it on the home page, and keeps refusing to use
it on sub pages (whether linked to or not). Opera was the best at it
(always using a /favicon.ico by itself, always obeying "related" links in
the head). Mozilla (and derivitives) was somewhere in the middle (obeying
links to an icon).

They were all a bit tempermental about accepting different icons for
different pages, wanting to use one for the everything at a particular host
address. And some were tempermental about the icon size being used.

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please delete some files yourself.

On Thu, 22 Jul 2004, Tim wrote:

"Alan J. Flavell" <flavell (AT) ph (DOT) gla.ac.uk> posted:

For HTTP resources there's no doubt: the *server* SHOULD[1] send the
correct MIME type. And if the server does what it SHOULD, then the
client MUST accept it (or reject the resource as defective/unusable) -
that's a security feature.

Although, in this case, there is no "correct" MIME type. There's an
experimental one, but no registered one.

You're right, but the server-provided MIME type is *still*
authoritative. The fact that it's experimental doesn't change that,
per RFC2616. If the server says it's text/plain, then RFC2046
applies: see e.g
http://www.cse.ohio-state.edu/cgi-bi...html#sec-4.1.3

This indicates plain text that does not contain any formatting
commands or directives. Plain text is intended to be displayed
"as-is", that is, no interpretation of embedded formatting commands,
font attribute specifications, processing instructions,
interpretation directives, or content markup should be necessary for
proper display.

That doesn't look like a favicon to me :-}

[you describe various tests]

MSIE was actually the worst at it.

No surprises there. Analogously, Netscape (<=4.*) also had defective
support for <font color=...>, despite (or rather, "because") Netscape
invented it. And MSIE had some pretty kooky results from <font
face=...>, especially in earlier versions - now who invented <font
face=...> ? - yup, you got it, it was MSIE.

It's by peer review and/or re-implementation by others that a design
is refined. I read somewhere that Adobe's definition of PDF was
improved and refined - also to the benefit of their own customers - by
input from another party who was trying to implement an independent
viewer (Xpdf, I think it was). This is a fairly widespread principle,
in fact.

cheers

p.s I got so upset by MSIE's early implementation of the favicon,
trundling around willy nilly through our web hierarchy looking for the
damned things and filling the log with 404 not found errors, that I
put an icon of a raspberry on the server, just to quieten it down. I
later got a nice email from a French lady asking me about the
relevance of this fruit to my pages - I don't think she was aware of
the "other" meaning of the term "raspberry" in English. ;-)

Dave Patton wrote:

If you are using a PC, IrfanView is free,

If you are using *Windows*, you mean. PC does *not* imply running Microsoft
Windows.

--
Shawn K. Quinn