Take the 2-minute tour ×

I have a site made with php which uses server side sessions throughout the site.
In fact, it's a site with a user login which depends on session variables and if there were a problem with all session variables, no pages would load at all.

On the site, there's an iframe that holds a feed of little messages from other users.
Those little messages have clickable photos next to them that open the user's profile.
Now, each page requires some formatting to open the user's profile on that specific page...there's really only a few problem pages, but those pages have to have the onclick functions formatted a little differently or they break the page.
So I set a session variable on each page ($_SESSION["current_page"]) that lets the feed know how to format the clickable photos. Now Firefox, Opera, Chrome, Safari all work as they are supposed to.
But IE6 and IE7 are having problems on the pages that require special formatting.
So after pulling my hair out a bit, I eventually got around to printing my session variables form the server.
And lo and behold, on the special pages, ($_SESSION["current_page"]) is always set to "main" instead of "special1" or "special2".

I printed the same session variable in Firefox and all the other browsers I mentioned and they print out "special1" or "special2" as they're supposed to.
Can anyone think of something - possibly related to the fact that the feed is in an iframe??? - that would cause IE to treat server side session variables differently or somehow launch page "main" silently in the background?
I have checked the feed very carefully for any reference to page "main" - it doesn't seem like there's any ways it's loading that page.

this doesn't make sense to me.

share|improve this question
To anyone else having this problem, I recommend completely closing down IE and re-opening it. This was happening to me in IE10, and I spent about half an hour trying all the solutions below to no avail. About 1 in 10 times the session would stay alive for long enough for me to log into my site, and then die again. After restarting the browser, everything works fine. –  Mark Aug 5 '13 at 19:45

12 Answers 12

up vote 9 down vote accepted

Try testing the page while using some sort of monitoring proxy (I use Fiddler) and see what pages the browser requests. That might give you some clues to what's going on.

Also, try capturing the requests/responses from different browsers and see what IE is doing differently (order of requests, content of requests?).

To pinpoint the problem, can you rewrite the code without using SESSION (it's mentioned in one of the other answers)? Maybe IE is accessing the pages in different order than other browsers? Maybe it is requesting the main page more than once, which means that the session var is set to "main"? Without session variables, the pages won't affect each other's state.

share|improve this answer
Re-writing a web app isn't always an option. Not only that, but it doesn't solve the original problem - just changes everything around it. Sean: Did you ever find a cause or solution? –  Kieveli Nov 26 '08 at 15:59
Kieveli: Good points. I wanted to suggest changing to a SESSION-less code to see if the problem persists. If it does not, it gives you a hint where to focus. Of course, if the app uses sessions pretty much everywhere, rewriting it just to pinpoint the problem is rather inefficient. –  Piskvor Nov 27 '08 at 14:15

Check the name of the server machine. IE has problems with machine names that contain '-' or '_' - they cannot maintain a session! I've had this problem twice in the past, and it always takes me weeks to figure out, and I'm shocked IE hasn't fixed it.

Just rename the machine to have no strange characters! You can get it working if you just use the IP address of the server in the url to test.

share|improve this answer
Actually, that's "broken as expected": DNS names are not supposed to contain underscores (as per the RFC). All other browsers tolerate them, but IE, in its infinite wisdom, just silently drops cookies of such sites. No indication, no nothing. Priceless. –  Piskvor Jan 2 '09 at 10:58
That was wonderful knowledge. The most irritating thing is that even IE's developer tools are just quiet. –  Jasmo Dec 23 '11 at 7:17
thank you for this insite, wow... this just blew my mind. –  Petrogad Nov 9 '12 at 14:09
As if I needed another reason to hate IE. We have dynamic subdomains on our website for customers to have their own profile pages, and it was all working fine until demo day when The Boss put in an underscore and everything broke. –  Patrick Apr 4 '13 at 16:22

IE has cookie issues with it's handling of iFrames which maybe causing the session issue you mention, take a look at these links




share|improve this answer
"Issues" isn't quite a correct summary. IE deliberately constrains cookies in cross-domain IFRAMEs unless a P3P Policy is present. –  EricLaw Jun 30 '09 at 20:53
@EricLaw-MSFT- A little late, but this explains exactly the issue recently had. –  DataHerder Sep 26 '11 at 18:29
@Sijin Thank you so much! You saved my day! –  andr111 Sep 9 '12 at 11:19

I thought some people might find the solution to this problem interesting. Fiddler certainly helped here. Thanks to Fiddler, I could see that I was, in fact, hitting the page main.php (thus setting the session variable moments after setting it on the target page), but the server was defaulting there after getting a 302 on the root of the site. This was all happening silently in the background, and before my onload="" javascript ran.

So I was sure something on those pages was causing an error, but not a catastrophic one.

here it is: <img src= "" >

IE was freaking out about the blank src attribute and hitting the server root and the defaulting to page main. I don't fully understand the mechanics happening here. I also don't understand if this is how IE is supposed to behave (it is a malformed img tag after all) or not. Is this a bug?

share|improve this answer
For legacy/historical reasons, IE treats the empty url "" as "/", which results in the HTTP request for the root URL. In your case, this is problematic because that request results in the setting of a cookie which changes your application's state. –  EricLaw Jun 30 '09 at 21:01
We just spent 3 days tracing a session problem back to this. At least now I know why... –  jodeci Dec 8 '11 at 9:18

In most cases, this php line at file begining will be enough:


If it isn't, for IE7 you may also try:


header('Set-Cookie: SIDNAME=ronty; path=/; secure');


header('Pragma: no-cache');

And if that doesn't work for IE6, you may use GET params for session ID:

header('location: land_for_sale.php?phpSESSID='.session_id());
share|improve this answer

I found if you added header('P3P: CP="CAO PSA OUR"'); to the top of your doc. It seems to have fixed the problem.

share|improve this answer

I have the same problem and it's SOLVED now.

Reference: http://www.dmitri.me/blog/ie-session-bug-is-solved/

The blank or empty attribute's values of any IMG tags cause the problem. For me, I used JavaScript to change IMG object's source to an empty value. Doing that could also make the problem.

share|improve this answer

If I understand it correctly, you are trying to use a session variable to pass data from a page to pages within iframes on that page? This doesn't seem a good way to go about it - why not just pass a GET variable into the iframe url i.e. ?current_page=special1 . I would think this would be more reliable as it does not rely on session state.

Remember also that the session variables will be the same for several pages of the same site that are open on a user's PC (e.g. on multiple tabs), which could cause odd behaviour.

share|improve this answer

Session data is stored on the server side, not the client. I would check the other pages, where this value would be set.

share|improve this answer

I had the same problem with ie7 and this is what I do:

If you have this problem using a IIS or Apache in Windows Server, look at the URL where you are redirecting it must be writed in the same way as the URL where you was before the redirection.

For example: site.com/pages/index.php redirection to site.com/Pages/index2.php is going to loose the session in IE7 because the capital letter in Pages.

share|improve this answer

I had this problem, and it was due to the date on my dev box being out. Firefox didn't mind, IE and chrome were seeing the session as being expired as soon as it was set.

share|improve this answer

Maybe it's session.cookie_lifetime. I have faced the same problem. I updated session.cookie_lifetime: 4500 to session.cookie_lifetime:0. This means the session cookie never expires until the browser shuts down.

share|improve this answer

protected by Community Sep 17 '11 at 11:27


Would you like to answer one of these unanswered questions instead?
