Corrupt archive?

So the file downloads just fine, but *something* is gzipping it? Weird.

Not really. A lot of sites you probably visit on a daily basis compress the HTTP traffic to save on bandwidth (and gzip is the most common compression scheme for this); the process just happens to be transparent—most of the time.

Gzip should only be used on HTML and plaintext, not on other files; if it's being applied indiscriminately, that's a bug.

So,the file was actually a zipped file of a zip file? All i had to do was install 7-Zip,extract the internal file and then extract the zipped contents from it.If i rename the inner zip file with a ZIP extension,i can open it normally with Winrar.(7-Zip opens the extensionless ZIP file just fine.)
Thank you very much,guys! I learned a lot from all of you.I knew it'd be worthy posting this issue here.I appreciate the help.Thanks!

P.S.: Does anyone have a clue why is this happening? I think i'm going to stick with 7-Zip to handle the files i get from RHDN.

I can see in Chrome that the response header contains "Content-Encoding:gzip" for a translation patch download.  I guess Chrome knows to gunzip first, but your IE8 installation doesn't.

Wow... this is a very interesting issue. Thanks for the additional information gentlemen. I did some more research. When the file is accessed directly, the web server will filter and sends the appropriate HTTP header. This means it will not encode zip files with gzip. When routed through PHP first, the web server will always do gzip, even on zip files. This is true for Apache with mod_deflate as we have, or any server side compression including Microsoft servers! Here is the same issue with Microsoft servers:

http://support.microsoft.com/kb/841120

And here is a page linking this to Apache as well:
http://stackoverflow.com/questions/1560075/zip-files-get-corrupted-by-ie

Our fixes are exactly the same! Both work. We can either disable the webserver's compression mechanism for downloads and serve the correct MIME types for the files (which allows your browser to suggest proper opening options). Or, we can allow it to operate and serve everything via a single MIME type.

I have chosen to disable the webserver compression for file downloads and serve the correct MIME types. This appears to have resolved the issue for IE.

Re-test and rejoice! 


P.S. IE will still send a blank referrer when right clicking 'Save As'. That will still receive a 403 from our site. I am still disallowing that at present time. I may choose to allow again later on when other better mechanisms are implemented to render it no longer useful.

Retested in Chrome.  The "Content-Encoding:gzip" is out of the response header (and even though the request says it supports it).  Looks like your mod worked.

(I just did a test a minute or two ago to see if it would still send gzip it even if the request didn't say that it supported it, but I think I didn't end up running it until after you made your server change, so I guess I'll never know...)

The request will always have gzip in it. That comes from your browser. If your browser supports it (Most everything in the past decade does), it will be sent in the request saying as such. It really shouldn't matter. It's supposed to work either way. This issue is funny. I'm not even sure where the responsibility lies as it spreads between site code, functionality of the browser, functionality of the webserver, and potentially PHP. It's inconsistent operation if nothing else.

Downloads are working properly again in IE.I just wanted to report it.Thank you for fixing it,Nightcrawler! Oh,and thanks again for all the guys who posted here! I learned a lot from you.