Take the 2-minute tour ×
Webmasters Stack Exchange is a question and answer site for pro webmasters. It's 100% free, no registration required.

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?

Answering questions:

After clearing Firefox's cache, presumably it happens again at some point?
Yes.

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

  1. Login session expires
  2. Try to access restricted page
  3. Get redirected to login page
  4. 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:

  1. the referring page determined by headers
  2. OR the referring page determined by session data
  3. OR to a default "redirect here after login" page that the developer specifies
  4. 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...

  1. 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)
  2. "/get" lingers in session data as the referer (e.g. it was the most recent referer)
  3. The AutoLogin component notices an expired session and logs in the user via cookie data
  4. Upon successful login, the AutoLogin component performs a 301 permanent redirect to /get because it's what's in the session
  5. 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.

share|improve this question
1  
It could have to do with the poor hash algorithm that Firefox uses for URLs. I've seen it cause issues with Firefox refusing to cache certain pages: stackoverflow.com/questions/664729/… and benlast.livejournal.com/29164.html –  Stephen Ostermiller May 19 at 17:50
    
"The URL in the address bar becomes /get, even if I type in /want." - errrm?! That is a redirection!? But there has never been a redirection on /want? (Browsers will cache redirects.) What are the browser/network requests when this happens? –  w3d May 19 at 18:23
    
@w3d, what I mean is that it is NOT the case that the browser loads /get and then is subsequently redirected to /want. The browser just loads /get (despite the user typing in /want and hitting Enter) and never even sends a request to /want. Also, none of these websites have ever had intentional redirects from one page to the other. –  Phantom Watson May 19 at 18:31
    
But the URL in the address bar actually changes from /want (the URL typed by the user) to /get? It's not simply loading the contents from \get? –  w3d May 19 at 18:35
1  
"This continues until I manually clear Firefox's cache." - and then presumably it happens again at some point? On the same /want URL? Or always a different/new URL? /want and /get are presumably unrelated? You aren't navigating by redirection, as opposed to ordinary links? Any login pages that redirect on success? –  w3d May 20 at 7:13

1 Answer 1

up vote 1 down vote accepted

It appears that this problem was being caused by an issue (a single mistyped character) with milesj's CakePHP Utility plugin, which has been fixed.

share|improve this answer
    
Thanks for updating the question with an answer. –  dan May 23 at 3:25

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.