This post originated from an RSS feed registered with .NET Buzz by Brad Wilson. Original Post: IE Bug, Caching and Downloading Feed Title: The .NET Guy Feed URL: /error.aspx?aspxerrorpath=/dotnetguy/Rss.aspx Feed Description: A personal blog about technology in general, .NET in specific, and when all else fails, the real world. Latest .NET Buzz Posts Latest .NET Buzz Posts by Brad Wilson Latest Posts From The .NET Guy

In ASP.NET, we have a download handler. We use this to send files to the users that they should be prompted to either Open or Save, rather than show inline in the browser. Through a combination of a couple sets of code, we ended up doing the equivalent of:

/* anti-cache code */     
Response.Cache.SetCacheability(HttpCacheability.NoCache);
Response.Cache.SetNoStore();
Response.Cache.SetExpires(DateTime.MinValue);

/* download prompt code */
Response.AppendHeader("Content-Disposition", "attachment; filename=" + ff.OriginalName);

This tells the browser not to cache the results (first set of code), and to give the Open/Save prompt (second set of code). Unfortunately, because of the way IE is architected, it always downloads to its cache, and then when the download is complete, puts the end result file in the right place. Logically speaking, IE put itself into a place architecturally when it would NOT permit the file to be downloaded. Of course, Mozilla had no qualms about downloading the file.

This is the kind of architectural decision that should never have surfaced to the user. I understand why they did it... they put the file into the cache until it's fully downloaded, and THEN move it around, so that the user won't see the local file until the download is complete. But it means that I had to end up special casing some code to turn off the anti-cache code for the prompted downloads.

Lame.