By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,986 Members | 1,537 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,986 IT Pros & Developers. It's quick & easy.

>> Quick question about Favicons

P: n/a
Something strange is happening, but I bet it is a quick fix. My
favicon image is showing up in the URL bar, for a couple of seconds,
but then it disappears and the default browser icon is displayed. When
I reload the page, the same thing happens. The correct icon appears
for a few seconds (while the page is loading), but then goes away. You
can see that here:

http://webdev.ucop.edu/tltc_ph2/index_icon.html
The code I am using is:

<LINK REL="SHORTCUT ICON" HREF="/favicon.ico" type="image/x-icon">
<LINK REL="ICON" HREF="/favicon.ico" type="image/x-icon">
Does anyone know what I am doing wrong? Thank you very much!
Jul 20 '05 #1
Share this Question
Share on Google+
27 Replies


P: n/a
ge********@ucop.edu (Gene Ellis) wrote in news:a74f92c1.0407191418.26cb0072
@posting.google.com:
Something strange is happening, but I bet it is a quick fix. My
favicon image is showing up in the URL bar, for a couple of seconds,
but then it disappears and the default browser icon is displayed. When
I reload the page, the same thing happens. The correct icon appears
for a few seconds (while the page is loading), but then goes away. You
can see that here:

http://webdev.ucop.edu/tltc_ph2/index_icon.html
The code I am using is:

<LINK REL="SHORTCUT ICON" HREF="/favicon.ico" type="image/x-icon">
<LINK REL="ICON" HREF="/favicon.ico" type="image/x-icon">
Does anyone know what I am doing wrong? Thank you very much!


There is nothing wrong with your HTML code, but there may be something
wrong with your saved favicon.ico.

You may want to recreate it. It does not display for me.
--
Edward Alfert
http://www.rootmode.com/
Multiple Domain Hosting and Reseller Hosting Plans
Coupon Code (Recurring $5/month Discount): newsgroup

Jul 20 '05 #2

P: n/a
Els
Gene Ellis wrote:
Something strange is happening, but I bet it is a quick
fix. My favicon image is showing up in the URL bar, for a
couple of seconds, but then it disappears and the default
browser icon is displayed. When I reload the page, the same
thing happens. The correct icon appears for a few seconds
(while the page is loading), but then goes away. You can
see that here:

http://webdev.ucop.edu/tltc_ph2/index_icon.html
The code I am using is:

<LINK REL="SHORTCUT ICON" HREF="/favicon.ico"
type="image/x-icon"> <LINK REL="ICON" HREF="/favicon.ico"
type="image/x-icon">

Does anyone know what I am doing wrong? Thank you very
much!


I don't even see it for a second. Not in Opera and not in
Firebird.

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?

--
Els
http://locusmeus.com/
Sonhos vem. Sonhos vo. O resto imperfeito.
- Renato Russo -
Jul 20 '05 #3

P: n/a
Gene Ellis schrieb:

http://webdev.ucop.edu/tltc_ph2/index_icon.html

The code I am using is:

<LINK REL="SHORTCUT ICON" HREF="/favicon.ico" type="image/x-icon">
<LINK REL="ICON" HREF="/favicon.ico" type="image/x-icon">


You are linking to the Server root /
But there is no favicon.ico at http://webdev.ucop.edu/
You have an Icon at http://webdev.ucop.edu/tltc_ph2/favicon.ico
So perhaps you want to link to /tltc_ph2/favicon.ico

Greetings, Jan

--
Axis of Evil! Countries not signing the UN Convention on the Right
of the Child: Somalia, USA
Jul 20 '05 #4

P: n/a
Els <el*********@tiscali.nl> wrote in message news:<Xn****************@130.133.1.4>...
Gene Ellis wrote:
Something strange is happening, but I bet it is a quick
fix. My favicon image is showing up in the URL bar, for a
couple of seconds, but then it disappears and the default
browser icon is displayed. When I reload the page, the same
thing happens. The correct icon appears for a few seconds
(while the page is loading), but then goes away. You can
see that here:

http://webdev.ucop.edu/tltc_ph2/index_icon.html
The code I am using is:

<LINK REL="SHORTCUT ICON" HREF="/favicon.ico"
type="image/x-icon"> <LINK REL="ICON" HREF="/favicon.ico"
type="image/x-icon">

Does anyone know what I am doing wrong? Thank you very
much!


I don't even see it for a second. Not in Opera and not in
Firebird.

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?


Hey! I made a real icon using Image Forge. You really can't see it?
Not even when going straight to
http://webdev.ucop.edu/tltc_ph2/favicon.ico ?
That's odd because I can see it just fine when I do that. Any other
suggestions?
Jul 20 '05 #5

P: n/a
On 19 Jul 2004 15:18:50 -0700, Gene Ellis <ge********@ucop.edu> wrote:
Something strange is happening, but I bet it is a quick fix. My
favicon image is showing up in the URL bar, for a couple of seconds,
but then it disappears and the default browser icon is displayed. When
I reload the page, the same thing happens. The correct icon appears
for a few seconds (while the page is loading), but then goes away. You
can see that here:

http://webdev.ucop.edu/tltc_ph2/index_icon.html
The code I am using is:

<LINK REL="SHORTCUT ICON" HREF="/favicon.ico" type="image/x-icon">
<LINK REL="ICON" HREF="/favicon.ico" type="image/x-icon">
Does anyone know what I am doing wrong? Thank you very much!

I don't see the favicon at all. Perhaps try the full path to the favicon
in the link.
Jul 20 '05 #6

P: n/a
Els
Gene Ellis wrote:
Els <el*********@tiscali.nl> wrote in message
news:<Xn****************@130.133.1.4>...
Gene Ellis wrote:
> Something strange is happening, but I bet it is a quick
> fix. My favicon image is showing up in the URL bar, for
> a couple of seconds, but then it disappears and the
> default browser icon is displayed. When I reload the
> page, the same thing happens. The correct icon appears
> for a few seconds (while the page is loading), but then
> goes away. You can see that here:
>
> http://webdev.ucop.edu/tltc_ph2/index_icon.html
>
>
> The code I am using is:
>
> <LINK REL="SHORTCUT ICON" HREF="/favicon.ico"
> type="image/x-icon"> <LINK REL="ICON"
> HREF="/favicon.ico" type="image/x-icon">
>
> Does anyone know what I am doing wrong? Thank you very
> much!
I don't even see it for a second. Not in Opera and not in
Firebird.

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?


Hey! I made a real icon using Image Forge. You really can't
see it? Not even when going straight to
http://webdev.ucop.edu/tltc_ph2/favicon.ico ?


In Firebird I get a long line of funny characters, in Firefox
it's asking me to download it, then with which program I want
to open it. On choosing Firefox, I get to see the icon.
That's odd because I can see it just fine when I do that.
Any other suggestions?


Could it be the server is giving it the wrong mime type?

--
Els http://locusmeus.com/
Sonhos vem. Sonhos vo. O resto imperfeito.
- Renato Russo -
Now playing: Jennifer Lopez & Marc Anthony - No Me Ames
(Tropical Remix)
Jul 20 '05 #7

P: n/a
All I see, Gene. is a bunch of garbage characters. Sorry!
Tony

Gene Ellis wrote:
Els <el*********@tiscali.nl> wrote in message news:<Xn****************@130.133.1.4>...
Gene Ellis wrote:

Something strange is happening, but I bet it is a quick
fix. My favicon image is showing up in the URL bar, for a
couple of seconds, but then it disappears and the default
browser icon is displayed. When I reload the page, the same
thing happens. The correct icon appears for a few seconds
(while the page is loading), but then goes away. You can
see that here:

http://webdev.ucop.edu/tltc_ph2/index_icon.html
The code I am using is:

<LINK REL="SHORTCUT ICON" HREF="/favicon.ico"
type="image/x-icon"> <LINK REL="ICON" HREF="/favicon.ico"
type="image/x-icon">

Does anyone know what I am doing wrong? Thank you very
much!


I don't even see it for a second. Not in Opera and not in
Firebird.

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?

Hey! I made a real icon using Image Forge. You really can't see it?
Not even when going straight to
http://webdev.ucop.edu/tltc_ph2/favicon.ico ?
That's odd because I can see it just fine when I do that. Any other
suggestions?


Jul 20 '05 #8

P: n/a
Els
Els wrote:
Could it be the server is giving it the wrong mime type?


Just checked it for you, 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>, but the other browsers
need the http headers, which are given by the server.

--
Els http://locusmeus.com/
Sonhos vem. Sonhos vo. O resto imperfeito.
- Renato Russo -
Now playing: Ofra Haza - Im Nin'alu
Jul 20 '05 #9

P: n/a
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.
but the other browsers need the http headers, which are given by
the server.


And are, AFAIK, definitive even where a type is provided in the <LINK>
attribute.

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/
Jul 20 '05 #10

P: n/a
Els
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?


It does.
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 just checked the headers with Lynx, and your server is
serving the icon as text/plain.
But I see your icon in IE, if I type the url of it in the
address bar. It is however not being picked up when I add your
page to my favourites, so maybe even getting the server to
give the right mime type might not be of help. Could well be
because http://webdev.ucop.edu/tltc_ph2/ is not the document
root of the server. That I'm guessing, I don't know.
but the other browsers need the http headers, which are
given by the server.


And are, AFAIK, definitive even where a type is provided in
the <LINK> attribute.


That's what I mean by IE not obeying the headers the server
gives. IE accepts what you say in the <link>, which is the
correct type for an icon.

--
Els http://locusmeus.com/
Sonhos vem. Sonhos vo. O resto imperfeito.
- Renato Russo -
Now playing: Annie Lennox - The Gift
Jul 20 '05 #11

P: n/a
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!).
Jul 20 '05 #12

P: n/a
Els
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 vo. O resto imperfeito.
- Renato Russo -
Now playing: New Kids On The Block - Tonight
Jul 20 '05 #13

P: n/a
Els <el*********@tiscali.nl> wrote in message news:<Xn****************@130.133.1.4>...
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
Jul 20 '05 #14

P: n/a
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 ;-)
Jul 20 '05 #15

P: n/a
Els
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 vo. O resto imperfeito.
- Renato Russo -
Now playing: Bow Wow Wow - Do You Wanna Hold Me
Jul 20 '05 #16

P: n/a
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.
I just checked the headers with Lynx, and your server
It's not my server; I'm not the op.
is serving the icon as text/plain.
That doesn't answer my question.
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.

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/
Jul 20 '05 #17

P: n/a
Els
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 vo. O resto imperfeito.
- Renato Russo -
Now playing: Counting Crows - Mr. Jones
Jul 20 '05 #18

P: n/a
Brian <us*****@julietremblay.com.invalid> wrote in
news:10*************@corp.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/
Jul 20 '05 #19

P: n/a
Tim
On Tue, 20 Jul 2004, Els wrote:
and what would be the correct way of specifying the
MIME type for it?

"Alan J. Flavell" <fl*****@ph.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.
Jul 20 '05 #20

P: n/a
On Thu, 22 Jul 2004, Tim wrote:
"Alan J. Flavell" <fl*****@ph.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. ;-)
Jul 20 '05 #21

P: n/a
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
Jul 20 '05 #22

P: n/a
Tim wrote:
Mozilla (and derivitives) was somewhere in the middle (obeying
links to an icon).


Mozilla's not automatically looking for favicons in the root directory
was an intentional design decision (I think there's actually a
configurable option, buried in the obscure settings without GUI
configuration interfaces, to enable such icon-finding, but it's off by
default). It wasn't considered to be polite to the webmasters to go
requesting files without explicit indication (e.g., via a LINK element)
that they were actually there.

--
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/
Jul 20 '05 #23

P: n/a
Tim
Tim wrote:
Mozilla (and derivitives) was somewhere in the middle (obeying
links to an icon).


Daniel R. Tobias wrote:
Mozilla's not automatically looking for favicons in the root directory
was an intentional design decision (I think there's actually a
configurable option, buried in the obscure settings without GUI
configuration interfaces, to enable such icon-finding, but it's off by
default). It wasn't considered to be polite to the webmasters to go
requesting files without explicit indication (e.g., via a LINK element)
that they were actually there.


Interesting to know, and easy to find in the about:config feature (using
icon in the filter gadget).

I suppose looking for something like an icon not explictly mentioned is
somewhat similar to automatically looking for /robots.txt or a P3P file.
By now there's probably quite a few of these sorts of things that browsers
look out for.

Working out what to do in the robots.txt file, or how to include favicons
wasn't too hard. I could sort of follow the P3P business, but attempting
to figure out what you'd do to implement the PICS rating thing was too
much of a headache. Not that I imagine not supporting either of those is
really going to harm my website.

I was amused to see IE getting served a favicon.ico file with a 406 error
response in my webserver logs. It appears it asks for something that it
doesn't say it supports, so the server warns it that it's getting
unacceptable data (for the browser) in response (i.e. what you're getting
might not be usable, maybe you should save it instead of view it).

--
My from address is fake, but the reply-to is real, though temporary. But I
really don't want private replies to usenet postings. Reply to the group.

Jul 20 '05 #24

P: n/a
On Sun, 25 Jul 2004, Tim wrote:
I was amused to see IE getting served a favicon.ico file with a 406 error
response in my webserver logs. It appears it asks for something that it
doesn't say it supports,

[...]

That's a classic!

Perhaps the server should be doing the same for HTML, since IE doesn't
normally say explicitly that it accepts it ;-)

Jul 20 '05 #25

P: n/a
Tim
Tim wrote:
I was amused to see IE getting served a favicon.ico file with a 406 error
response in my webserver logs. It appears it asks for something that it
doesn't say it supports,

"Alan J. Flavell" <fl*****@ph.gla.ac.uk> posted:
That's a classic!

Perhaps the server should be doing the same for HTML, since IE doesn't
normally say explicitly that it accepts it ;-)


It certainly is. I was wondering if that was why it sometimes wouldn't
show the favicon, but then there doesn't seem to be any consistency to
MSIE's behaviour. Trying to second-guess it's second-guessing is an
exercise in frustration.

One the same thread of messing with headers and the like, I've been trying
to get my head around content-negotiation and multi-views using Apache.
I've been having a bit of a look at headers going in either direction, and
MSIE is one of those which does plenty of dumb things that make it near
impossible to use in one aspect.

e.g. Given /example.txt /example.html /example.xhtml and so on (various
different formats of the same file), there's no way for me to preselect
which version I think would be best, if all of those formats are supported.
IE typically gets the text file (or something worse). Apache seems no
better, it doesn't seem to let me set q factors for that sort of
content-negotiation (file based), only letting me do it if I start using
var files.

--
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.
Jul 20 '05 #26

P: n/a
On Sun, 25 Jul 2004, Tim wrote:
One the same thread of messing with headers and the like, I've been trying
to get my head around content-negotiation and multi-views using Apache.
Would that be Apache 1.3 or 2.0 ? They've done some work on the
detailed implementation in Apache 2, and I haven't quite got up to
speed on it myself.

N.B we are in the wrong place for a proper discussion of this.
If you really want to take it up, I suggest moving to
comp.infosystems.www.servers.unix (which is where Apache normally gets
discussed in the comp.* hierarchy), or in some Apache-specific forum
(I don't normally participate in the latter, but no matter).
I've been having a bit of a look at headers going in either direction, and
MSIE is one of those which does plenty of dumb things that make it near
impossible to use in one aspect.
Certainly there are problems with it. Not least that a reload on IE
presents a different Accept header than the original request, and thus
might very well produce a different document variant after server
negotiation!
e.g. Given /example.txt /example.html /example.xhtml and so on (various
different formats of the same file), there's no way for me to preselect
which version I think would be best, if all of those formats are supported.
Generally speaking, you need to assign a qs value to the different
variants. For Apache 2 see
http://httpd.apache.org/docs-2.0/con...on.html#better
Apache seems no better, it doesn't seem to let me set q factors for
that sort of content-negotiation (file based), only letting me do it
if I start using var files.


This is a bit of a mystery, actually. Some informants are convinced
that it's OK to write e.g:

AddType "text/html; charset=utf-8; qs=0.9" .whatever

as a configuration statement (in the usual contexts), and that the
specified qs= values will be used during MultiViews negotiation.
However, I've found no documentation - for Apache 1.3 nor for 2.0 -
which advertises this as a supported feature.

Nor did I find time to investigate it, I'm afraid.

Of course, a side effect of doing that would in any case be to
serve-out the qs= values on the Content-type header: a
properly-implemented client which had no use for qs= values in that
context would ignore them, but there have been problems in the past
with clients getting stuff that they hadn't expected on the
Content-type header and getting confused, so I'd have to advise
caution anyway.

hth
Jul 20 '05 #27

P: n/a
On Sun, 25 Jul 2004, Alan J. Flavell wrote:
AddType "text/html; charset=utf-8; qs=0.9" .whatever

as a configuration statement (in the usual contexts), and that the
specified qs= values will be used during MultiViews negotiation.
However, I've found no documentation - for Apache 1.3 nor for 2.0 -
which advertises this as a supported feature.


Well, here's a very superficial test.

http://ppewww.ph.gla.ac.uk/~flavell/...iviews/foo.txt,
foo.html, bar.txt and bar.html have been defined with different
qs= values in AddType directives:

<Files foo.*>
AddType "text/html; qs=0.005" .html
AddType "text/plain; qs=1.0" .txt
</Files>

<Files bar.*>
AddType "text/html; qs=1.0" .html
AddType "text/plain; qs=0.005" .txt
</Files>

and are being served out with a version of Apache 1.3.*

Using IE6 (whose only relevant Accept: is "*/*"), requesting foo
gets negotiated to the .txt version; requesting bar gets negotiated
to the .html version.

Using Mozilla (which requests HTML with a q of 0.9 and plain text with
a q of 0.8), the same results are achieved.

So this is definitely "working" (i.e in the sense that the configured
qs= values are evidently being used in the MultiViews negotiation
calculations), even if not explicitly documented.

With e.g the "web developer's toolbar" for Mozilla, one can display
the relevant HTTP response headers, e.g

Content-Location: bar.html
Vary: negotiate,accept
TCN: choice
Last-Modified: Sun, 25 Jul 2004 13:25:03 GMT
Etag: "98007-34-4103b4af;4103b8ef"
Accept-Ranges: bytes
Content-Length: 52
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: text/html; qs=1.0

As I mentioned before, the qs= value /is/ included in the Content-type
response header (and might confuse some client applications).

I've also tried it locally on a test installation of Apache 2, and
here too it seems to "do the business".

I repeat, this really isn't the right group for discussing this. I'm
just reporting some observations - this isn't in any way a personal
recommendation of what to do, because I haven't tried it in practice
to look for gotchas.

While we're on this topic: I posted something here earlier this year,
see
http://groups.google.com/groups?selm...6.ph.gla.ac.uk
which on one point I think I have to correct myself about. At that
time I wrote

| AFAIUI, wildcard choices should only be considered if no explicit
| match can be found, irrespective of your qs values.

It appears that this isn't what Apache does, after all.

It now looks as if Apache 1.3 treats MSIE's */* as having effectively
the same qs value as its application/msword etc.

My revised interpretation would be this. If you offer your HTML, XHTML
and MS-Word versions as having equal source quality, then - by
observation - Apache 1.3 will send MS-Word, but this is probably only
because it comes first in MSIE's Accept list. If you offer them as
having different source quality values, then your highest source
quality gets sent (this would be XHTML in the context of that earlier
discussion - which is of course not what you're trying to achieve).

Apache 2, on the other hand, is documented as assigning an implied
request quality (q) of 0.01 to */* if no q value is explicitly
assigned to it by the client. So this is the q value which Apache 2
will use for HTML or XHTML content types when requested by MSIE: it
means that if you want content negotiation to send HTML to MSIE, then
you'd have to assign a sufficiently small qs value to any
application/msword variant to get it below that. Let's try (say)
0.008.

Note that MSIE implies that it accepts XHTML just as happily as it
accepts HTML, whereas in fact it does not. To be sure of sending it
text/html rather than application/xhtml+xml, you'd have to assign a
just-slightly-higher qs factor to your HTML variant than to your XHTML
variant. However, Mozilla requests XHTML with a q of 1.0, whereas it
requests XHTML with a q of 0.9, see this extract from the Accept
header:

... ,application/xhtml+xml,text/html;q=0.9, ...

Suppose you assign qs=1.0 to HTML and (say) 0.99 to XHTML. Then the
sums for Mozilla will be 1.0 x 0.9 = 0.9, and 0.99 x 1.0 = 0.99, so
Mozilla will get sent XHTML in preference.

Does this make some kind of sense now? If you're strictly following
the Apache documentation, then you would need to assign these qs
preferences via a type-map (.var) file. The open question here is
whether this trick with qs= values on AddType configurations will
cause any significant problems for client software.

cheers
Jul 20 '05 #28

This discussion thread is closed

Replies have been disabled for this discussion.