Eye Glazer

Oh boy. I became aware of another crippling bug with Internet Explorer today (IE6, IE7, & IE8). In short, when downloading a .zip file that is transmitted using gzip encoding, IE doesn't unpack it before passing it on to the end-user. So instead of getting a .zip file as expected, you get a gzip file that contains the file you wanted to download. To the average client, it appears that the file is corrupted---and in the end, that's all that matters. Based on the various discussions found when Google-searching for "gzip ie7", it appears the problem is (at least) in the Vista versions of IE. I happen to be on Vista x64 SP2 and IE8, so that's at least one environment where the bug is present. The server is irrelevant, but if you must know, I'm using IIS 6 (Windows 2003 Server) with .Net 2.0; the page's extension is ".aspx", but I use the content-disposition header to give the download a ".zip" extension. There is this one page where so...

If you ever want to make it so IE7 will not download a file, set the Cache-Control or Pragma headers to "no-cache". Some time in the past, I thought I learned that when you want to stop a proxy server from caching a file (apart from or in addition to the actual client), you set the following headers: "Cache-Control: no-cache" and "Pragma: no-cache". In C# ASP, that equates to the lines Response.Cache.SetCacheability(HttpCacheability.NoCache); and Response.AppendHeader("Pragma", "no-cache"); (I believe the Response.Cache.SetMaxAge(TimeSpan.Zero); line was also suggested to me as part of this, but I can't remember anymore.) If you send either of those 2 headers, you'll get a completely useless error message from IE7 when clicking a link to the page---you'll see "Internet Explorer cannot download filename from domain/server ... Internet Explorer was not able to open this Internet site. The requested site is either ...