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 someone at Microsoft has been notified about the problem, but the Microsoft contact appears very inexperienced; level-2 customer support at best. I hope a real engineer has actually been notified as they indicated.
There appears to be a workaround (for me, at least). If your response indicates the non-standard content-type of "application/x-zip", IE8 does not screw up the download. Both "application/zip" and "application/x-zip-compressed" trigger the bug, however. What I have done is simply send x-zip for "MSIE" user-agents, and I've verified that IE8 and IE6 (Win2k) will download the file properly with this hack in place.
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 someone at Microsoft has been notified about the problem, but the Microsoft contact appears very inexperienced; level-2 customer support at best. I hope a real engineer has actually been notified as they indicated.
There appears to be a workaround (for me, at least). If your response indicates the non-standard content-type of "application/x-zip", IE8 does not screw up the download. Both "application/zip" and "application/x-zip-compressed" trigger the bug, however. What I have done is simply send x-zip for "MSIE" user-agents, and I've verified that IE8 and IE6 (Win2k) will download the file properly with this hack in place.
Comments