Okay, I have the weirdest problem. (Warning: Wall of text ahead)
I’m tracking a variable in my $_SESSION, that is set to different numbers depending on what tab a user clicks via AJAX. For convenience I also set that variable on the target site to be sure it’s set (for people who don’t have JS enabled or similar issues).
With every browser that works just fine. Now I was testing with IE, and as soon as you click another link on the target site for the tab with value 2, the value resets itself to 0. Every other tab (where possible values are 0, 1, 2 of course, 3 and 4 as there are five tabs) works fine.
If I comment out the convenience assignation in the target site (every target site has that btw) tab 2 suddenly works too. Although debugging this showed that the target site sets the value from int(2) to int(2) … so no real change happened (but still, removing this not-changing change fixes it).
Now the question is:
What the &@#$ is Internet Explorer doing to screw up a perfectly fine php session?
I’ve checked my entire project multiple times and debugged large parts of it to find the cause of this issue but found nothing. There are only three lines where the value is set.
-
The session object is created for the very first time and get’s the value
0.
I’ve checked this and it really is only called at session creation. (I’ve surrounded the line with an echo that should’ve been visible somewhere if it was called but it never was) -
The receiving method of the AJAX-call set’s the value to whatever it reads from
$_GET.
This works and survives a followingwindow.location.href="..."to redirect to the target site. -
On the target site to ensure that the value was set for people without JavaScript enabled.
This seems to be where it get’s hairy, although debugging didn’t show any wrong behaviours what so ever.
I’ve also checked if somehow serialization is failing to serialize the 2 for some reason, but checking the session file in /var/lib/php5 showed a perfectly healthy and properly set 2 after the tab was clicked and the page changed.
Upon debugging session initialization (both, directly after session_start() and after the serialized object had done it’s wakeup routines) I found the value to be 0 on the following site request (obviously after clicking the tab and being redirected to the target site). So I thought it would be a problem with php derping the deserialization. So I’ve created another property for testing, stored a 2 in it and let it load a few times and it always loaded as 2. Additionally, any other browser I have tested (which is Firefox and Chrome) does not have any issues with tab 2… So php doing silly stuff is busted too.
Anthoer idea that came to my mind was IE’s funny privacy stuff, that likes to forget cookies and jokes like this, so i tracked the session ID through all the page and AJAX requests.
It never changed. So getting a new session object with the default value of 0 is busted too. Additionally, any other tab works with IE.
Lastly I checked the javascript stuff that does all the AJAX things. The very exact same code runs for all three tabs, so there can’t be a real reason for it to fail with a 2 but I did anyways.
And just as I expected nothing was wrong there either. All the calls went through properly and got the proper responses from the server to continue their work.
Right now I don’t know what’s left to check or debug. I don’t even understand how IE is able to manipulate a server side variable that’s stored in a file on the server between requests.
I know it must have to do with IE, because if it was a mistake in my serverside programming I would see the effects in other browsers too, right?
Does anyone have any idea on what else I could try to do to debunk this???
And of course, here are all the specs of software and stuff that I’m using:
Internet Explorer 9.0.8112.16421 on Windows 7 32bit as VirtualBox guest (bug present)
Internet Explorer 9.0.8112.16421 on Windows 7 64bit on a real machine (bug present)
Firefox 16.0.2 on Fedora 17 x64 on a real machine (bug not present)
Firefox 16.0.1 on Windows 7 64bit on a real machine (bug not present)
Chrome ? (installed ~2 weeks ago) on Windows 7 64bit on a real machine (bug not present)
Opera Mobile 12.10.ADR-1211271253 on Android 2.3.3 on a real phone (bug not present)
Server is Apache 2.2.16 with PHP 5.3.3-7 on Debian 6 running kernel 2.6.32-5-amd64
Update 3rd Dec 2012:
Apparently it has to do with a flash video embedded in the target page. Putting it in the target page of one of the other tabs made me able to reproduce the issue for other tabs too.
It also only seems to occur with videos loaded; audio files do not trigger the bug.
It’s a bit curious though, since the javascript code involved does nothing but add an embed. The player in question is Nonverblaster, which is free and didn’t make any trouble so far.
Apparently it also makes use of http://code.google.com/p/swfobject/.
With flash player uninstalled the bug is gone too, so it definitely has to do with this video player. I’m not yet sure how it does it, since loading .swf and .flv files has nothing to do with php sessions, but it somehow seems to do it.
It appears that when IE asks the server for the .swf, it doesn’t send the session cookie. This then causes the cookie to be regenerated by the server.
Some related discussions –
Most sources tend to agree that a solution is for the server to identify the request that relates to loading the flash content, and include it in the original session. Or at least prevent a new session being created.