[BlueOnyx:16536] Re: favicon.ico for admserv

[Michael Stauber]

Hi Michael,

> Actually this is wrong. The errors we see in the logs are as a result of
> browsers that request the favicon.ico even if it is NOT in the page source.
> I always put a favicon.ico file at /usr/sausalito/ui/web/favicon.ico and the
> errors disappear.

I tried it and put the favicon from www.blueonyx.it into
/usr/sausalito/ui/web/favicon.ico and my Firefox on Ubunto 14.04 LTS
wouldn't use it. It only started using it when I added ...

<link rel="shortcut icon" href="http://5209r.smd.net/favicon.ico"
type="image/x-icon">

... to the respective GUI header.

It might be that not all browsers handle this in the same way. Hence I'm
following the recommendation from W3.org:

http://www.w3.org/2005/10/howto-favicon

The relevant section is this:

------------------------------------------------
Method 2 (Discouraged): Putting the favicon at a predefined URI

A second method for specifying a favicon relies on using a predefined
URI to identify the image: "/favicon", which is relative to the server
root. This method works because some browsers have been programmed to
look for favicons using that URI. This approach is inconsistent with
some principles of Web architecture and is being discussed by W3C's
Technical Architecture Group (TAG) as their issue siteData-36. To
summarize the issue: The Web architecture authorizes site managers to
manage their URI space (for a given domain name) as they see fit.
Conventions that do not represent community agreement and that reduce
the options available to a site manager do not scale and may lead to
conflict (since there is no well-known list of these predefined URIs).
One practical consideration illustrates the problem: many users have Web
sites even though they do not have their own domain name. These users
cannot specify favicons using the second method if they cannot write to
the server root. However, they can use method one to specify a favicon
since it is more flexible and does not constrain the site manager to use
a single favicon at a single place on the site.

There are a few other well-known encroachments on URI space, including
the "robots.txt" file and the location of a P3P privacy policy. The
Technical Architecture Group is exploring alternatives that do not
impinge on URI space without license.
------------------------------------------------

-- 
With best regards

Michael Stauber