Seemingly at random, when I attempt to go to a webpage (such as /want), another webpage (such as /get) on the same subdomain is loaded in response. This has been happening for many months on a set of websites that I'm developing, both in the localhost and production versions. I tried to ignore it as a bizarre Firefox fluke, but I spotted the same thing happening in the wild on another user's computer, so now I'm worried that whatever's happening might make these websites unusable for some people.
- Cache issue: This continues until I manually clear Firefox's cache.
- URL changes: The URL in the address bar becomes /get, even if I type in /want.
- No redirect code: There is nothing in the front-end or back-end code that redirects the user.
- Content irrelevant: The error continues when the content of /want changes, even if /want is changed to a blank page. If the content of /get changes, those changes show up, so it's not a static snapshot of a page that's being loaded.
- Firefox only: I haven't noticed this happening in any other browser, and if Chrome and Firefox both attempt to load /want at the same time, only Firefox loads /get. I'm currently using Firefox 29.0.1, but this has been happening with the last few versions too.
- Indiscernible pattern: It's inconsistent which two pages this happens with, but they seem to always be pages that I load frequently and navigate directly between.
- Using CakePHP: The affected websites all run in different subdirectories of the same installation of CakePHP 2.4.5.
I've been scouring the internet trying to find some clue about what's happening or even a description of this happening to someone else, and I've come up empty. I'm not even sure how to test this to figure out what the root cause of the problem is, or to eliminate the possibility that something in the code of my CakePHP sites might be the cause.
Update, following testing:
A network sniffer confirms that when I attempt to load /want, there's only a request for /get taking place. However, running an AJAX request for /want in Firebug shows the following:
GET http://example.com/want 301 Moved Permanently Response Headers: Location: http://example.com/get GET http://example.com/get
So Firefox has cached a 301 redirect, but there's nothing in the website's code that currently or has ever set the status to 301. Firefox seems to be randomly deciding to cache 301 redirects on its own. And inconsistently, too, as sometimes these redirects change on their own without either the website changing or Firefox's cache being cleared.
Guys, level with me. Firefox is just straight-up haunted, isn't it?
After clearing Firefox's cache, presumably it happens again at some point?
On the same /want URL? Or always a different/new URL?
Sometimes the same, sometimes different.
/want and /get are presumably unrelated?
As much as two pages on the same website can be.
You aren't navigating by redirection, as opposed to ordinary links?
Nope, just ordinary links and pasting the /want URL into the address bar. The only thing in the site that would ever redirect the user to /get isn't even in /want, it's in...
Any login pages that redirect on success?
Huh. Well, CakePHP sends the user through these steps...
- Login session expires
- Try to access restricted page
- Get redirected to login page
- If login is successful, redirect back to restricted page
By default, CakePHP does redirects with code 302 (found / moved temporarily), which shouldn't be cached.
However, I'm pretty sure that all of the affected sites are using the AutoLogin component from milesj's CakePHP Utility plugin, which does include a 301 permanent redirect upon successful auto-login. In that line, the user is 301-redirected to whichever of these is non-null, in order:
- the referring page determined by headers
- OR the referring page determined by session data
- OR to a default "redirect here after login" page that the developer specifies
- OR to the site's root page (/)
Since I never specified a "redirect here after login" page, everything should be automatic and send users to either the page they intended to go to or to / after login. The only way I could imagine this /want -> /get behavior coming out of the AutoLogin component is if somehow...
- The user tries to load /want in a way that sends no referer data in headers (e.g. Firefox was closed down and loads up the same tabs again, or the URL is entered manually)
- "/get" lingers in session data as the referer (e.g. it was the most recent referer)
- The AutoLogin component notices an expired session and logs in the user via cookie data
- Upon successful login, the AutoLogin component performs a 301 permanent redirect to /get because it's what's in the session
- Firefox permanently caches the redirect from /want to /get
Hunting through the CakePHP codebase, though, I can't quite manage to wrap my head around how it manages referer data in the session or whether or not it's actually possible for one request to inherit the referer from another request, which is the only way this scenario seems to be possible.
I've created an issue in the AutoLogin component's GitHub page so someone smarter than me can hopefully help evaluate my suspicion.