I <3 IE8

No, not really. 

On our recently completed Vogue Archive project, IE8 support was a requirement, due to a large number of potential users being stuck at the office on Windows XP with no freedom to install a better browser.  (We had a similar requirement for Firefox 3.6 support, but nowhere near the same kind of trouble with that browser though it was definitely the second worst browser in our field).

Background

The Vogue archive is an HTML5^* + Silverlight application: we have two viewers, one built in HTML5 (for tablets and desktop browsers that support it), one built in Silverlight (for all desktop browsers). Both viewers are housed within the same HTML5 "chrome" - see yellow sections in the image below:

IE8, of course, was released years before HTML5 started its meandering way through the standardization process, so it should hardly be expected that IE8 should support HTML5.

Mmm, Cookies!

It should be expected, however, that IE8 could support HTTP cookies properly.

Not so much.

We got an error report from the field that when IE8 users logged out from the archive, and then logged back again, the logon process went through, and then promptly redirected them back to the unsecured welcome page at the start of the logon process. Hm.  Sure enough it did.  The excellent error report also stated that for some reason they were seeing two authentication cookies, one of which was empty.  Could that have something to do with it?  Huh? 

[Quite some time later]

The problem was indeed related to the double-cookies, but it appears it was actually caused by how IE8 interprets cookie expiration dates:

The standard way to delete a cookie is to create a new cookie with the same name, in the same domain (and path), with an expiration date set to a date in the past.  A pretty standard date to use is the 'epoch' start date (JavaScript's beginning of time) - midnight of 1/1/1970, GMT, represented as "Thu, 01-Jan-70 00:00:01 GMT;"

For whatever reason, IE8 sees this date, and attempts to convert it to local time - in our case (EDT) 4hrs earlier: 12-31-69 08:00:01 PM.  Slight problem - since '69 was before the start of the epoch, this is then further interpreted as meaning 2069 (never mind the second bug that a winter time should be converted using EST - aka GMT-5hrs).  So rather than creating a new cookie that immediately expired and thus was deleted, we ended up with a new very long-lived cookie.

To complicate things further, as a brute force way for us to make sure we delete both local and domain cookies (we don't know the preference of the client), in our delete-cookie script we actually create two expired cookies, one for each domain (i.e. vogue.com and archive.vogue.com).  It appears the login/logout process got confused and sometimes read one cookie (empty, expiring in 2069) and sometimes the other (valid session cookie).

Solution

While the analysis was complex, the solution was simple - we now use an expiration date of 1/1/2000 rather than 1/1/1970 - now IE can convert times all it wants, and it still stays a date in the past, and the cookie is expired.

Tell Them Again

I <3 IE8.