Why do my users' downloads randomly stall in IE?

Question

I have downloads that are triggered by a redirect in an iframe.

1. user clicks the "download" button
2. our JS fetches the download URL from the server (it's a timing-out url so it has to be done this way)
3. the iframe is redirected to the download url, which has content disposition of attachment, so the browser starts the download without changing the location of the page.

this works well for all users and browsers... except some IE users.

I've tried to reproduce the problem and here's what I've come up with:

• if the "save or open" dialogue boxes are clicked through quickly, the download always works
• if the "save or open" dialogue boxes are clicked through slowly (like 10-20 seconds) the downloads sometimes works, sometimes doesn't. i haven't been able to find a pattern.

Here's what it looks like when it gets stuck:

The issue is not from the link timeout on S3 -- my experiments above are well within the time window.

What could be causing these sporadic download failures?

update

Server logs suggest that the downloads are being completely sent to the user.

Answer 1

I did some tests downloading the LLVM test suite, a 78 Megs file using IE 9 in Windows 7. The downloads starts when you click the link. Internet Explorer does not wait for you to confirm or cancel. IE saves the bytes to your download directory in a file named fizzbuz.partial. IE will catch up with your choice by either renaming the file when its done or deleting it if you cancel.

It could be a timing problem or an HTTP problem.

Timing problem

Is it possible that another process opens the file, maybe even locking it ? Maybe a overzealous anti-virus or real-time backup software ? Chances are the close and rename operation (which must take place since the server sent the whole file) goes something like this :

1. Write the last, valid bytes to the fizzbuzz.partial file
2. Close the file
3. Rename the file

What if a process grabs the file for exclusive read between 2 and 3 ? Maybe that application makes some changes to file like writing to an alternate NTFS stream which are confusing to IE ?

Keep in mind that browser plug-ins are also notified of the end of the download. Another kind of timing problem could be caused by a plug-in that monitors the download, and seeing it end, does some operation. That operation could fail or never return on some occasions.

Try to reproduce the problem without any anti-virus running (a better test than just whitelist the file) and without any browser plug-ins loaded.

HTTP problem

The server and client must agree on the way to end the connection. You must either :

1. Close the connection at the end of the transfer
2. Specify the length of the download

It is hard to debug this from a distance, but if at all possible, capture a network trace of the download and look for these clues :

1. The Content-length header is absent or maybe off-by-N (the browser will wait forever for N byte(s) that will not come) ?
2. Does each client have the same proxy configuration ?
3. Is the non-working clients downgraded to HTTP 1.0 ? (There is a setting named "always use http 1.0 through proxy"

From your screen shot, it looks like the browser was not able to compute the estimated time of arrival but there is no correlation between that and the download.

Answer 2

I don't know how IE handles it, but in other browsers while you choose where you want to store the file the download has already started. What's the timeout of your download URL? Have you tried setting it higher? Does it work more than once? (if not, check your log for failed access attempts). Good luck.

PS: if nothing works, try this.