views:

527

answers:

5

I am experiencing a strange behaviour of my application in Chrome browser (No problem with other browsers). When I refresh a page, the cookie is being sent properly, but intermittently the browser doesn't seem to pass the cookie on some refreshes.

This is how I set my cookie:

$identifier = / some weird string /;
$key = md5(uniqid(rand(), true));
$timeout = number_format(time(), 0, '.', '') + 43200;
setcookie('fboxauth', $identifier . ":" . $key, $timeout, "/", "fbox.mysite.com", 0);

This is what I am using for page headers:

header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
header("Cache-Control: no-cache, must-revalidate"); // HTTP/1.1
header("Expires: Thu, 25 Nov 1982 08:24:00 GMT"); // Date in the past

Do you see any issue here that might affect the cookie handling? Thank you for any suggestion.

EDIT-01:

It seems that the cookie is not being sent with some requests. This happens intermittently and I am seeing this behaviour for ALL the browsers now. Has anyone come across such situation? Is there any situation where a cookie will not be sent with the request?

EDIT-02:

Here are the HTTP Headers:

Request Method:GET
Status Code:200 OK

REQUEST HEADERS

Accept:application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Referer:http://fbox.mysite.com/dashboard
User-Agent:Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US)
AppleWebKit/532.5 (KHTML, like Gecko)
Chrome/4.1.249.1045 Safari/532.5

RESPONSE HEADERS

Cache-Control:no-cache, must-revalidate
Content-Length:8903
Content-Type:text/html
Date:Tue, 06 Apr 2010 09:25:26 GMT
Expires:Thu, 25 Nov 1982 08:24:00 GMT
Last-Modified:Tue, 06 Apr 2010 09:25:26 GMT
Pragma:no-cache
Server:Microsoft-IIS/7.5
X-Powered-By:PHP/5.3.1 ZendServer

Thanks again, for any guideline.

+1  A: 

The way you handle your cookies is completely fine, everything seems okay in your code, the problem seems to lie with Chrome.

Although Chrome Issue# 3014 deals primarily with a Java applet, it seems that's what you are experiencing.

Anthony Forloney
@Anthony: Thank you for that reference. I tried a lot of searches and could not find anything that speaks of an issue with Chrome related to my problem. I am wondering how other websites handle their cookies. They are still running smooth on Chrome.
Nirmal
@Nirmal, No problem for the reference. Searching was a bit tough, that was the only thing I had found. I see theirs an open bounty and I hope someone can resolve your issue, best of luck.
Anthony Forloney
+3  A: 

One question, one suggestion -

Question - why are you doing the number_format(...) on the time(), since a time() + 43200 should be sufficient.

Suggestion - Have you looked at the clocks between the client and the server. Since you're only giving a 12 hour difference between the two, if there is a big clock skew or a disagreement on when GMT is between the two machines you might find that you're sending a cookie that is destine to expire in the very near future.

koblas
Thank you for the reply. The site is in an intranet and all machines are in the same office. Moreover, all client machines are configured to auto-update time from a time server. So I could say, this is not a time issue.
Nirmal
+1  A: 

I've seen an issue similar to this before. I would double-check to see if the path is correct.

I'd imagine a www.domain.com is different from domain.com , as is www.domain.com/ (with trailing forward-slash)

Beyond that, check that PHP has access to write it's sessions to file with proper write permissions (it's a different directory depending on distro, but phpinfo() should tell you what directory it is trying to use. )

I've run into both of these before. The first one gives no error and seems to mimic what you're experiencing, the second one gives a file-write-access error of some sort but if errors aren't displayed you might not see that.

Garrett Bluma
Thanks for some ideas. The site is in an intranet and does not go out of it's sub-domain. So that means there is no www or changing subdomain in it. For the sessions, I have re-written PHP's session handling to use a database and it works with no flaw.
Nirmal
He's not using sessions, it seems, so it would hardly affect his example.
arnorhs
A: 

Is your application served from the http protocol or file:// ?

Chrome does not store cookies with local apps, and that's by design. You can change this behaviour with the command line switch:

--enable-file-cookies

It's served through http protocol. I have gone through all the checks and still couldn't trace the problem. Even tried recreating the entire cookie logic, but still losing persistence. But your's was an useful information. About the Chrome's file cookie behaviour. Thanks for that.
Nirmal
+2  A: 

The only thing I can think of, having seen your header information, is that PHP is outputting something before you set the cookie. If that is the case, setcookie should return false and you'll get a warning "Cannot send session Cookie - headers already sent" As Bart S. suggests, turn on error_reporting(E_ALL) and try outputting the return value of setcookie to verify this isn't the case.

Also, try just using setcookie in the basic case with just a name and value and check the response headers again. Then cut out all of your code except for the setcookie and if that works, bring all your code back using divide and conquer :)

James Wheare
Ha! I figured it out. A database transaction handler class runs in between pages and was throwing an exception in rare situations before the next page loads. But, curiously, the header redirection works seamlessly even after an error is printed out by the handler. Now I've fixed my db class, things look fine. Thanks for the hint and that helped at the right moment! :)
Nirmal