Solved

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

Posted on 2008-10-21
23
971 Views
Last Modified: 2013-12-08
Dear fellow Microsoft and Linux gurus,

I was recently made lead developer of the XMB open source project.  I am looking a bit dumb right now because our Internet Explorer users have been unable to download our ZIP archives.  :(  Rather than continue to bang my head against the wall, I've decided to come to the Experts for help.

The common symptoms are:  IE6 and IE7 users receive about 300 kB of the file, which is then saved to disk or opened in a corrupt state.  Firefox, Opera, and other browser users do not have any trouble at all.

We have a typical LAMP server, and I should be able to answer any configuration questions.

Test the following URL:  http://www.xmbforum.com/download/XMB-1.9.10-Patched.zip

That file was created with PKZIP v8.00.0038

Notice, however, I can't reproduce the problem at this URL:  http://www.xmbforum.com/download/XMB-1.9.7-rc3.zip

What the heck is the deal?
0
Comment
Question by:miqrogroove
  • 13
  • 7
  • 2
  • +1
23 Comments
 
LVL 4

Expert Comment

by:Dizzybro
Comment Utility
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
0
 
LVL 11

Author Comment

by:miqrogroove
Comment Utility
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.
0
 
LVL 11

Expert Comment

by:jgmontgo
Comment Utility
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.
0
 
LVL 4

Expert Comment

by:Dizzybro
Comment Utility
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..
0
 
LVL 11

Author Comment

by:miqrogroove
Comment Utility
jgmontgo,  Our clients are public, everywhere.  If even 25% of them have this problem then I am doing a bad job :)
0
 
LVL 11

Expert Comment

by:jgmontgo
Comment Utility
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.
0
 
LVL 11

Expert Comment

by:jgmontgo
Comment Utility
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.
 
0
 
LVL 11

Author Comment

by:miqrogroove
Comment Utility
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.
0
 
LVL 11

Author Comment

by:miqrogroove
Comment Utility
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
0
 
LVL 11

Author Comment

by:miqrogroove
Comment Utility
FWIW, I set "ExpiresActive Off" to disable mod_expires in one of the directories, and there was no change in IE.
0
 
LVL 11

Author Comment

by:miqrogroove
Comment Utility
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?  :/
0
How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

 
LVL 11

Expert Comment

by:jgmontgo
Comment Utility
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.
 
0
 
LVL 11

Author Comment

by:miqrogroove
Comment Utility
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."
0
 
LVL 11

Author Comment

by:miqrogroove
Comment Utility
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?
0
 
LVL 11

Author Comment

by:miqrogroove
Comment Utility
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?
0
 
LVL 11

Author Comment

by:miqrogroove
Comment Utility
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
0
 

Expert Comment

by:ldargin
Comment Utility
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.
0
 
LVL 11

Expert Comment

by:jgmontgo
Comment Utility
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.
0
 
LVL 11

Author Comment

by:miqrogroove
Comment Utility
jgmontgo you are very close, but have a look at the Apache documentation ;)
0
 
LVL 11

Accepted Solution

by:
jgmontgo earned 500 total points
Comment Utility
After looking at the docs I see a couple of things that may be related, of course I dont see your actual settings so it is hard for me to know what might have been the issue:
EnableSendfile is apparently an imporntant setting because there are cases where Sendfile will fail, so setting this to off might have resolved the issue, but this is not my number one pick.
LimitRequestFieldSize could be the culprit too, although less likely, as we did see less data transferred in the initial packet.
MaxKeepAliveRequests is responsible for limiting the number of requests per connection when KeepAlive is on. If this number were too low it might cause this problem. If KeepAlive were off it might also cause the problem, as you mention earlier it looked like BlueHost had other traffic that appeared to be keeping the connection alive.
TimeOut is probably the culprit because the request would fail if the timeout was reached. If this value was too low (default is 300) it might cause this problem.
 
0
 
LVL 11

Author Comment

by:miqrogroove
Comment Utility
"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.
0
 
LVL 11

Author Closing Comment

by:miqrogroove
Comment Utility
Thanks and congrats ;)
0
 
LVL 11

Expert Comment

by:jgmontgo
Comment Utility
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.
0

Featured Post

Why You Should Analyze Threat Actor TTPs

After years of analyzing threat actor behavior, it’s become clear that at any given time there are specific tactics, techniques, and procedures (TTPs) that are particularly prevalent. By analyzing and understanding these TTPs, you can dramatically enhance your security program.

Join & Write a Comment

It is possible to boost certain documents at query time in Solr. Query time boosting can be a powerful resource for finding the most relevant and "best" content. Of course the more information you index, the more fields you will be able to use for y…
Citrix XenApp, Internet Explorer 11 set to Enterprise Mode and using central hosted sites.xml file.
This Micro Tutorial will demonstrate how nuggets on the Web are formatted by using Chrome Developer Tools. These tools would not only view the site's CSS but it can also modify it and save the CSS to use on your own site.
Shows how to create a shortcut to site-search Experts Exchange using Google in the Chrome browser. This eliminates the need to type out site:experts-exchange.com whenever you want to search the site. Launch the Search Engine Menu: In chrome, via you…

743 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

15 Experts available now in Live!

Get 1:1 Help Now