Chrome's behaviour may mimic other browsers, but they're all perpetuating a bad practice by guessing at the existence of a resource, instead of following explicit URLs in the page source. A client shouldn't request a favicon unless it sees something like this in the head section:
The same goes for robots.txt, sitemap.xml, crossdomain.xml, apple-touch-icon.png (really?) and all the other poorly conceived ideas that fill web server logs with unnecessary 404 errors.
It's actually not so clear-cut. The solution of presenting resources within the head of the page only works if those resources are supposed to be loaded as a result of visiting the page. That's not true of robots.txt (in fact, you want a crawler to read robots.txt before it does anything else). It's also not true of crossdomain.xml (which Flash and Java use to pre-flight cross-domain communication requests).
Personally, I'd rather require the files to be in known locations than force every client that wants the information to make a request and parse HTML.
Just to play devil's advocate, but I like this practice. Convention over configuration. Just place the favicon in the root directory of the site, give it an explicit URL if you need one.
Of course, many people end up putting an explicit reference in anyway, so, eh. Probably not that helpful.
The 404 errors in particular seem like a very Machiavellian way to get sites to support your browser's features. You have to wonder how many people add in a favicon or iTouch icon just to shut up the errors up.
Maybe I'm being pedantic, but the HTML reference to the favicon is the convention. I personally roll my eyes when I deploy something and see tons of 404s in my log for favicons that I've not made available or suggested that browsers attempt to load.
>HTML reference to the favicon is the convention //
No, the convention is that a favicon.ico file is found in the root of the site and that you can instead locate an icon by supplying a URL. Sucks as a convention.
Interestingly Google on their search homepage (for me at least) are using a microdata markup and not serving an explicit icon:
