Internet Explorer can't download ZIP files from this server!

Odds are you are uploading the zip files to the sever in ASCII format instead of Binary

I also found that the hard way. I own a TF2 server (much simpler but same concept) and while uploading .bz2 files for fast downloading of maps, it would upload in ASCII format and corrupt them, even though i had it set to automatically detect what to upload it as.


If i were you i would set your ftp program (if you use one) to upload all files as binary, (temporary), and see if that uncorrupts them.


Hope it helps ;p
Diz

Dizzybro: The files on the server are not corrupt.  You can confirm this by downloading the files.

I have also been unable to reproduce the problem when I put the files on a different web server.  This leads me to believe it could be an HTTP configuration issue.

I tried both of the URL's and found ZIP files that were complete, no problem opening them at all. I am using IE7.
Are your users all at the same location (or a couple of locations)? I ask this because both ZIP files look fine to me, so I am wondering if there is a client configuration issue.

Oh ok i see, its not the server's files that are corrupt, but IE6 and 7 users seem to get downloads that stop early and go corrupt.


I downloaded fine like you said with firefox 3.0

And according to jgmontgo he did it with IE7

So it must be a client error. Unless they are not connected in any way at all...thats quite the conundrum..

jgmontgo,  Our clients are public, everywhere.  If even 25% of them have this problem then I am doing a bad job :)

Ok,  so that dosent make this any easier to figure out.
You mentioned "This leads me to believe it could be an HTTP configuration issue." I am not sure I agree, simply because, as you put it, "Firefox, Opera, and other browser users do not have any trouble at all." If it were a configuration issue one would think that all browsers would be experiencing a problem.
But then, maybe it is a timeout issue on the server.
I was able to pull down both files, using IE7 so it worked for me. I assume, from your last comment, that some of your IE users are able to pull the files down.
Other than some obscure timeout issue I wonder if there isnt something unique about the users that are having problems. Like are they using dialup, or are they in another country, etc.
What version of Apache are you using and what else are you using on that server.

Ok, I checked some of the other downloads on your site and found one that would not work for me, so now I see what is happening.
So it is not client configuration, it must be something to do with the HTTP Server or at least something on that side. So I would look at the following two things:
1. Server settings such as timeouts. I would also look at the log files to see if there is anything that might point you in the right direction.
2. It is also possible that you are experiencing a network problem (local or ISP) where some packets are being damaged somehow.
One thing to keep in mind while testing this issue. If a file downloads fine one time, it should download fine as long as it is in the browsers cache. Cleaning that cache would force the file to be downloaded again.
 

Something I should probably reiterate is that I've been unable to reproduce the bad behavior on some servers.  I have a website hosted by the good people at BlueHost that works very smoothly if I just FTP this file in there and then download it using IE, cleared cache and all.

I'm attaching a side by side comparison of the server diagnostic from rexswain.com for a known good server and a known bad server.

Could all of this be caused by cache headers?  Or am I barking up the wrong tree?
headers.txt

FWIW, I set "ExpiresActive Off" to disable mod_expires in one of the directories, and there was no change in IE.

I really thought this one would work.  I exported all of the archive subfolders to a server that didn't have PKZIP installed, created a new archive using win's Compressed Folders and uploaded that to the web server.  No change at all.

*Something* has to be wrong with this server.  What's the next step in diagnosing it?  Packet analyzer?  :/

Just to verify, you said "I set "ExpiresActive Off" to disable mod_expires in one of the directories, and there was no change in IE." I assume you cleared the IE Cache before trying it again.
From the behavior it is clear that the file is not fully transferred, so there must be some sort of error condition occuring. Using a Packet Analyzer may be the next best step in trying to narrow down what exactly is happening.
 

Here is a response I got from the PKZIP tech support:

"I was able to reproduce your problem on Vista running IE7.  Once I restored IE defaults from TOOLS, OPTIONS, ADVANCED, RESTORE ADVANCED SETTINGS I could then save and open your ZIP file.  I recommend comparing the IE advanced settings from a machine that saves and opens your ZIP file from one that does not open it correctly."

Okay gurus, put your thinking caps on.  We're going to fix this once and for all.  I ran a packet analyzer and discovered an interesting pattern.

If I clear the cache in IE, click the download link, and very quickly click Save and browse quickly, then the whole file will download.

If I clear the cache in IE, click the download link, click Save, and then wait a solid 10 seconds at the browse dialog, then the file never downloads from xmbforum.com.  At my BlueHost server, the file downloads every time.

I couldn't find anything in the packet analysis to suggest that the server is dropping the connection.  The analysis does show part of the file being transfered before browsing and after browsing, and it looks like IE is sending a packet to the server with the TCP "No more data from sender" flag at the end.  The server sends its ACK with the same flag and then there is no more network activity.

I am by no means a TCP master so I could be interpreting this wrong.

Where shall we go from here?

I've tried the packet analyzer with the BlueHost server now, and here are the biggest differences:

In the server's first response, BlueHost sends an HTTP header followed by 1050 bytes of the ZIP file.  xmbforum.com sends an HTTP header only, the file begins in the next packet.

Both servers transfer a portion of the file while IE is waiting for the user to select Open/Save/Cancel.

Both servers transfer more of the file after I click Save while waiting at the Browse dialog.

BlueHost will complete the transfer when I'm done browsing.  xmbforum.com will not.

The capture shows no TCP packets being exchanged while the Browse dialog is open with xmbforum.com whereas BlueHost will do this.  Are these keep-alive packets?

I've got the answer now based on the above information.  500 points will be awarded to the first expert who figures out what it is :D

Set up an FTP download link for that file; it should then work fine with IE.
I know that IE sniffs HTTP downloads, but I do not know why it corrupts them.

Without seeing the trace files, but based on what you have found it is looking like we have a TCP/IP setting issue on the server. My first inclination is to blame it on frame size, afterall one of the differences between the two hosts was the amount of data transferred in the first packet with BlueHost vs xmbforum.com.
Yet another part of me wants to believe you are just expiring the TTL, could be the case as the file downloads if save is hit immediately, but not if there is a 10 second delay. If this were the case we would drop the packet and return an ICMP packet to the server. You did not mention this packet so this is probably not the cause.
The fact that the browser is sending a FIN or "No more data from sender" tells me the browser is essentially giving up. This may be the result of a failure in the three way handshake, but then that is just a guesse. It may also be the result of a closed or reset TCP Connection (I found a very interesting paper that talks about this):
http://pages.cpsc.ucalgary.ca/~carey/papers/2005/TCP-Resets.pdf
 Assuming we have a connection issue there are settings that you could have adjusted (like frame size) that would make a difference.
In any case, it would be interesting to know what you did to resolve the situation.

jgmontgo you are very close, but have a look at the Apache documentation ;)

"The TimeOut directive currently defines the amount of time Apache will wait for three things:
  1. The total amount of time it takes to receive a GET request.
  2. The amount of time between receipt of TCP packets on a POST or PUT request.
  3. The amount of time between ACKs on transmissions of TCP packets in responses."

As soon as I saw bullet 3 there I knew that was the culprit.  I checked the httpd.conf file for this server and it was customized with "TimeOut 5".

Aparently Internet Explorer is the only web browser that will both interrupt a file transfer and then refuse to re-establish a connection to resume it.

Thanks and congrats ;)

I missed bullet 3, but you are right. It definitely makes sense that this is what was happening, especially with a TimeOut of 5, very low.
Nice work and thanks for the points.