When considering application compatibility, it turns out that there are a number of differences between the biggest challenges affecting Internet-facing public websites and the biggest challenges affecting web applications run in the enterprise.
One change between Internet Explorer 6 and Internet Explorer 8 which seems to be disproportionately affecting the enterprise is Session Sharing – the fact that multiple windows and tabs share the same session. Coming from IE6, where you have one process per window, and no tabs, this can take a bit to wrap your head around.
To deeply understand what is going on, we need to explore what we are doing to make that magic happen. A web application is nothing more than a series of completely independent HTTP requests. There is no state whatsoever. We create the illusion of state by sending along a little tag with each request, indicating “hey, it’s me again – return a response custom tailored for me.” This tag can be anywhere in the request. It can be in the URL, in the headers, or in the body of the request.
Many server development environments initially implemented the illusion of state using cookies. They were hidden in the header, which was convenient if you try to bookmark something. It also gave you the flexibility to either make the cookie persistent or non-persistent. If you make the cookie persistent, then it gets saved to a file, and it comes as no surprise that this is shared by every IE window and/or tab on the computer.
Where it gets complicated is when you make the cookie non-persistent. When this is the case, the cookie is simply held in memory. Since memory is relative to a process, it won’t be shared between process. It will, however, be shared within the same process.
And here is where things begin to differ from what you were used to with Internet Explorer 6. When you double clicked on the IE icon, you typically ended up getting a new process. You didn’t have tabs. So, you ended up taking an inadvertent dependence on the particular process model of IE6. Now, this is no longer the case. Why? Because processes aren’t cheap. Having a big pile of processes lying around is extremely inefficient and degrades performance, so we take a smarter approach. Incidentally, this is not just true of Internet Explorer – you’ll see the same thing on other modern browsers.
So, we have “everything on this computer” (persistent cookies) and “everything in this process” (session cookies), but what we really want in those scenarios where session sharing is a problem (it’s often a benefit) is neither – we want “everything in this specific tab” – that’s what we happened to accidentally have in IE6 because of the particular way in which it was implemented, but we certainly don’t want to base our applications on a dated process model that isn’t supported by modern browsers in general. So, how do we achieve that?
HTML 5 has thought of this, and addressed it with sessionStorage – but until you have reached critical mass for browsers supporting HTML 5, and invest in redesigning your apps to support this, that doesn’t help you.
One option is to include the session ID in the URL – ASP.NET explicitly supports this with its Cookieless state option. However, by mangling the URL (it goes in the URL directly, rather than the query string), you create an unbookmarkable set of web pages, which is sometimes a problem, but if that is an option, it’s a fast and easy way to accomplish that.
Another alternative is to prefix the name/value pairs you are storing with a value unique to a particular window/tab. How would this work?
A final alternative is to use File / New Session to ensure you get a new process (or launch from a shortcut starting iexplore.exe with the -nomerge argument), which works fine if users are technical or can be depended upon to follow a series of steps consistently. However, this leaves you with a dependency on a legacy process model, and consequently a browser dependency as not all modern browsers provide for such an option.
Wherever possible, my hope is to help my customers remove dependencies on a dated and no-longer-used-anywhere process model, but we have a bit of a bridge to cross over until we have HTML 5 everywhere, so I hope that one of these suggestions work for you. If you have other suggestions which you have tried and were successful with I would love to hear them!