How A Missing Favicon Broke My App for Chrome Users(allinthehead.com)
allinthehead.com
How A Missing Favicon Broke My App for Chrome Users
http://allinthehead.com/retro/359/a-favicon-broke-my-app
5 comments
If Varnish strips cookies from all static resources, then simply embedding an <img> tag that points to a nonexisting image on the page should be able to destroy your session too, no? Sounds like a very dangerous setup.
Not a dangerous setup as much as a misconfigured one with dangerous side effects.
The problem is easily resolved by having Apache respond with a 404 to any requests for non-existant static resources. Which is of course what it should be doing in the first place.
The problem is easily resolved by having Apache respond with a 404 to any requests for non-existant static resources. Which is of course what it should be doing in the first place.
If you have bad links, and this PHP scheme, then Google will probably flag you for duplicate content issues too.
Not actually Chrome's fault here. But it's a great example of the idea that no issue is caused by a single thing going wrong - it's a few things going wrong at the same time that causes the most problems.
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:
<link rel="shortcut icon" href="/path/to/favicon.ico" />
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.
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.
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:
<meta itemprop="image" content="/images/google_favicon_128.png">
See eg http://dev.w3.org/html5/md/#names:-the-itemprop-attribute
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:
<meta itemprop="image" content="/images/google_favicon_128.png">
See eg http://dev.w3.org/html5/md/#names:-the-itemprop-attribute
[deleted]
And then you get no favicon for media urls?
Chrome should report the favicon request in its network inspector.
Chrome did once upon a time and currently has a bug report filed: http://code.google.com/p/chromium/issues/detail?id=110449
It would be nice to see AppCache traffic there as well.
There is an open bug report for favicon requests not showing up in the network tab.
http://code.google.com/p/chromium/issues/detail?id=110449
http://code.google.com/p/chromium/issues/detail?id=110449
So, why did it only break Chrome?
I think Chrome is more insistent in trying to fetch resources. I don't know for sure, but I think it's likely that other browsers also failed, but only occasionally.
Firefox, for example, quickly gives up if it can't fetch a resource, and so would fail but then work a second time. A glitch like that could easily be overlooked as a mis-click or network error.
Firefox, for example, quickly gives up if it can't fetch a resource, and so would fail but then work a second time. A glitch like that could easily be overlooked as a mis-click or network error.
This is some impressive detective work. Especially considering how common the "redirect all wrong URLs to index/search" behavior is.
There is nothing wrong about redirecting a missing page to a known index or search page. It's only if you decide to also return a 200 OK message with the request that you are breaking the web. 404s can have valid content, you don't have to blackhole your user into nothingness. At the same time, your 404 page shouldn't change the state of your application's transaction either (like generating a new session ID).
1. Users are assigned a session cookie when they land on a PHP page. A CSRF token is associated with a session when users visit the login page.
2. Favicon requests were going to PHP instead of a static resource. Normally that's fine, since PHP will see the cookie.
3. But since the request looked like it was for a static resource, Varnish stripped the cookies before passing it back to Apache/PHP. That meant PHP issued a new session that replaced the old one.
All in all, a very tricky interaction between technologies (especially since Chrome didn't display the favicon request).