We recently ran into a problem where all Safari/WebKit users trying to log into our application on a client's server were unable to do so. Firefox users had no problems. I tracked the problem down to a cookie issue. It turns out that the client's server time was off (approx. 45 minutes earlier than it should be). This had the effect of making cookies with an expiration date of less than 45 minutes in the future expire immediately on Safari. Firefox somehow bypassed the influence of the incorrect server time and set the expiration time for cookies as you'd expect given a correct server time. One cookie required for our login lasts less than 45 minutes, and given its inability to be set on Safari, this caused Safari users to be blocked. I have since requested that the client adjust their server time, which now allows Safari users in. However, it seems to me that in an ideal world an incorrect server time would not cause Safari cookies to go bad. I don't know how Firefox manages to avoid the same issue, but adopting whatever intelligent cookie parsing they use for cookie expiration time would be welcome. This was verified with Safari release and Webkit builds 44282+, but for all I know the problem could lie outside of Webkit. Note that sending Firefox's user agent from Safari did not affect the situation, so I didn't suspect a problem on the server side.
This bug hasn't been evaluated or assigned in the past couple years. I just checked and it seems to still exist. I've got a way to reproduce now (without needing to change the server time of a live server): 1) Take two computers (in my case I just used my desktop Mac and a MacBook). 2) Enable web server on one of them. 3) On the *same* computer with the web server enabled, create the following PHP script: <?php if (empty($_GET['test'])) { setcookie('test',1,time()+1800); die(header('Location: '.$_SERVER['PHP_SELF'].'?test=1')); } else echo 'Cookie is '.(empty($_COOKIE['test']) ? 'NOT ' : '').'set.'; ?> This script is designed to set a cookie that expires in 30 minutes, then redirect, then check to see if the cookie still exists or if it has expired immediately. 4) On the *same* computer with the web server enabled and the PHP script created, set the computer's clock back 1 hour. 5) On the *other* computer (without server/script), load the PHP script that was created via http in Safari. Result: Safari will say "The cookie is NOT set." Firefox will say "The cookie IS set." Is it possible that Firefox is getting the server's reported time, calculating an offset before server time and client time, and then dynamically adjusting the cookie expiration time accordingly? My mind is boggled a little bit.
Sorry that this bug has been neglected. This is almost certainly not a WebKit issue. Please report it to Apple via <http://bugreport.apple.com> for Apple engineers working on this code to investigate. I don't know if your explanation is correct, but it sounds reasonable.
> Is it possible that Firefox is getting the server's reported time, calculating an offset before server time and client time, and then dynamically adjusting the cookie expiration time accordingly? My mind is boggled a little bit. Yes, but Firefox is the only browser that does this. We discussed the issue in the cookie working group at the IETF and they agreed to remove this behavior because it's super nutty.
Probably no need to report to bugreport.apple.com then. Thanks Adam!
(In reply to comment #3) > > Is it possible that Firefox is getting the server's reported time, calculating an offset before server time and client time, and then dynamically adjusting the cookie expiration time accordingly? My mind is boggled a little bit. > > Yes, but Firefox is the only browser that does this. We discussed the issue in the cookie working group at the IETF and they agreed to remove this behavior because it's super nutty. Do you mean Firefox has agreed to remove this behavior? I'm less interested in having Safari match FF's behavior as I am seeing all browser vendors handle the situation the same way. That will help remove ambiguity for us developers. At least in my experience it probably would have resulted in the issue being more quickly recognized as a server misconfiguration than an incompatibility with the Safari browser as it was originally reported to us. I'd love to look into getting the behavior standardized (with Safari's behavior, as agreed upon by the cookie working group), whether that means going to W3C or the Firefox team. But if there's already action being taken, I won't bother.
> Do you mean Firefox has agreed to remove this behavior? Yes. > whether that means going to W3C or the Firefox team. But if there's already action being taken, I won't bother. Cookies are handled by the IETF, not the W3C. If you'd like to file a bug against Firefox (ccing dwitte) that would probably be helpful. I suspect they're busy shipping Firefox 4 right now though.
(In reply to comment #6) > Cookies are handled by the IETF, not the W3C. If you'd like to file a bug against Firefox (ccing dwitte) that would probably be helpful. I suspect they're busy shipping Firefox 4 right now though. Great. I will file a bug with Firefox with a mention about the IETF decision. You may close this bug.