Most web designers and developers I know view the slow demise of Internet Explorer with happiness and impatience. Especially when developing web applications in PHP, older versions of IE (looking at you, versions 6 & 7) can be a real bear. Countless CSS issues aside, Microsoft built these versions in manner that seems to have near-total disregard for all web standards.

One particular IE bug eluded me for a long time. When building PHP web apps that required the user be remembered (anything to do with shopping carts, login systems, etc), IE would loose the session. But only older versions of IE, not 8 or 9. Nor other browsers like Chrome, Opera, Safari or Firefox. Absolutely maddening because it is very difficult to test these issues with a dynamic site- there are plenty of page rendering sites out there, but you really need a native instance.

To understand why the below code works, you have to first understand how Session works. When you open that first session_start() call in PHP, it is going to create a tiny text file called a cookie on the users computer. All this text file will contain is the unique ID of this session, which corresponds to a text file on the server. So if you have a web form that POSTs the user’s email into $_SESSION['email'], this will be physically stored on the server in a directory somewhere, and the user’s machine has a reference to this. HTML is stateless, meaning that each time user requests a page (visits it in their browser), this page is “dumb” and doesn’t know the user from adam. This is where the cookie comes in, identifying the user to the script and allowing it to pull personalized content out.

So where this goes wrong is that while most modern browsers handle the Session Cookie in a predictable and normal way, IE7 and lower versions behave strangely. It is very easy to confuse IE in this case and cause it to drop the cookie, so when session_start() is called the session is blanked out and restarted. When researching it I came across many different explanations for this behavior, from the size of the cookie, to having to call session_write_close() before a redirect, etc. In my experience it is mostly caused by a mismatch between the HTTP header and the cookie. The code linked patches the issue by explicitly setting the session cookie.

The more frustrating part (and the value to me) was trying to figure out how to diagnose. Here’s what I did in order to find and squash the issue:

  1. Some form submissions were coming through blank. I first thought it was automated spam triggering the script(which it is in some cases), but I soon learned legitimate users were having problems.
  2. I tried to diagnose it by finding a computer still running IE6, but was unable to reproduce the issue. I spent literally days trying different browser rendering solutions without finidng a workable, simple or cost efective diagnostic tool.
  3. Instead I set a small php logging script in the include files, which recorded the IP address, User agent, and Session ID. After some data gathering and reverse lookup on the UA, it was clear we had an IE-only problem.
  4. I then did echo session_id() and used the 100% free and awesome testing tool IE Netrenderer to verify that indeed a new session ID was being generated on each page load.
  5. Finally I implemented this fix, and since have not had a single problem with it since.

Comments

Powered by Facebook Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Set your Twitter account name in your settings to use the TwitterBar Section.