The problem is that Internet Explorer does not handle file dowloads without caching over https very well. Or at all. According to knowledge articles on Microsofts website the problem occurs when having one or two of the http headers:

Pragma: no-cache
Cache-control: no-cache,max-age=0,must-revalidate

Previously I have have just omitted the http header “Pragma: nocache” for IE but it seems it does not always help.

So, whether you want it or not, the solution to the IE https download cache problem is to tell IE to cache the file.

if ((isset($_SERVER["HTTPS"]) && strtolower($_SERVER["HTTPS"] == "on")) &&
    preg_match("/MSIE/", $_SERVER["HTTP_USER_AGENT"])) {
	header('Pragma: cache');
} else {
	header('Pragma: no-cache');
}

February

March

April

Conclusion

None really. I just think it’s good that a more modern browser is finally gaining market share.

A couple of days back I received an email from Vitaly Melnikov. He pointed out that when using my technique for making javascript calls to a remote script together with intervals, Internet Explorer will evetually bulge. Is there a memory leak in Internet Explorer?

As I started investigating how IE handles memory when manipulating the DOM using javascript I found out that IE has a garbage collector which does not release memory just because you say so. So what looks like a memory leak might not be one. However, there are other memory problems using DOM in IE.

When using dom methods to manipulate the html dom tree in the browser you eventually end up removing nodes in the tree. Methods like removeChild() exist for this purpose. These methods also return a reference to the removed child node if you whish to work with the node some more. So it is understandable that it does not free any memory. However, there is no difference if you explicitly delete the node. Consider the simple example below. It removes a script tag and adds a new one from in the html head element.

function memTest()
{
  var head = document.getElementsByTagName('head').item(0);
  var child = document.getElementById('myScript');
  head.removeChild(child);
  delete(child);

  var script = document.createElement('script');
  script.src = 'http://dotvoid.com/fake.js';
  script.type = 'text/javascript';
  script.id = 'myScript';

  head.appendChild(script);
}

I have been running this using the method setInterval() to call this over and over. For example:

setInterval(memTest, 5);

After 3000 calls Internet Explorer used almost 3 Mb more memory than before. There are circumstances when I have used this technique but mostly you wouldn’t do it exactly like this.

What you probably would do in an application is to use dom methods to create and delete more advanced widgets – or whole user interface elements like dialogs. In this case you could easily end up creating and deleting many thousands of dom nodes in a short time as the user navigates your user interface.

Further tests reveal that Internet Explorer does not release memory if you have a javascript variable that reference a node in the html document. The memory will not be released even if you leave the current page for another page. This could be a problem if you create more advanced intranet applications that is used extensively. Unless the user minimizes the explorer window once in a while that is.

So is this a memory leak. No not really. As soon as you minimize Internet Explorer the memory will be released. As the garbage collector can release the memory at this time means it still has control over the memory.

So the problem is limited to cases where you have a large application that relies heavily on dom manipulation, use it extensively for a couple of days without ever closing or minimizing the browser window.

What you can do as programmer is to keep track of all your dom references and before leaving for another page, catching the unload event, release all references to dom elements on the page as IE does not release dom nodes referenced by javascript variables when loading another page.