

How A Missing Favicon Broke My App for Chrome Users - drewmclellan
http://allinthehead.com/retro/359/a-favicon-broke-my-app

======
nbpoole
So, the components at play here:

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).

~~~
eridius
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.

~~~
drewmclellan
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.

~~~
pbhjpbhj
If you have bad links, and this PHP scheme, then Google will probably flag you
for duplicate content issues too.

------
AndrewDucker
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.

~~~
jackalope
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" />
    

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.

~~~
phillco
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.

~~~
drivebyacct2
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.

~~~
pbhjpbhj
> _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>

------
abraham
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>

------
alexchamberlain
So, why did it only break Chrome?

~~~
drewmclellan
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.

------
thekungfuman
This is some impressive detective work. Especially considering how common the
"redirect all wrong URLs to index/search" behavior is.

~~~
uxp
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).

