Why is this HTTP request continually looping?
I'm probably overlooking something really obvious here.
Comments are in to help explain any library specific code.
public function areCookiesEnabled() {
$random = 'cx67ds';
// set cookie
cookie::set('test_cookie', $random);
// try and get cookie, if not set to false
$testCookie = cookie::get('test_cookie', false);
$cookiesAppend = '?cookies=false';
// were we able to get the cookie equal ?
$cookiesEnabled = ($testCookie === $random);
// if $_GET['cookies'] === false , etc try and remove $_GET portion
if ($this->input->get('cookies', false) === 'false' AND $cookiesEnabled) {
url::redirect(str_replace($cookiesAppen开发者_Python百科d, '', url::current())); // redirect
return false;
}
// all else fails, add a $_GET[]
if ( ! $cookiesEnabled) {
url::redirect(url::current().$cookiesAppend);
}
return $cookiesEnabled;
}
Firstly, I wanted an easy way to check if cookies were enabled. I achieved this, but in the event of no cookies, there was an ugly ?cookies=false
in the URL.
That was OK, but then if you reloaded the page and did have cookies enabled again, I wanted to redirect the user so it stripped off ?cookies=false
in the URL (allowing the method to recheck and learn that cookies now are enabled.).
After $cookiesEnabled = ($testCookie === $random);
, there are 4 cases:
$cookiesEnabled
is true and$_GET['cookies'] === 'false'
is true$cookiesEnabled
is true and$_GET['cookies'] === 'false'
is false$cookiesEnabled
is false and$_GET['cookies'] === 'false'
is true$cookiesEnabled
is false and$_GET['cookies'] === 'false'
is false
Case 1 is handled by the first if
block. The return
statement is intended to handle cases 2 and 3; the second if
block is intended to handle only case 4, but it catches both case 3 and 4. In case 3, the URL already has ?cookies=false
, but since $cookiesEnabled
is false, we redirect to add ?cookies=false
, and cycle back into case 3.
You must be leaving something out since there is no loop in that code. If you meant that the browser is looping (e.g. getting continuous redirects), then I recommend installing the Live HTTP Headers extension to Firefox and watch what the browser and server are actually saying to each other. Putting in some logging code in the snippet above might also be instructive.
Update for comment:
Then I really recommend putting in print statements inside the if
s so you can see which ones you're going through and what the various values are. Clearly something is not getting set the way you thought it would be, so now you need to find out what it actually is.
One thing I have encountered several times is that the code itself is OK, but there is a .htaccess file that is working against you, so go double check any .htaccess files in any of the directories, starting from DOCUMENT_ROOT.
精彩评论