"File couldn't be downloaded" in Internet Explorer with ASP.NET MVC

Question

So I'm returning a FileContentResult from an action like this:

return File(pck.GetAsByteArray(), "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet", "MyExcelFile.xlsx");

When clicking "Open" in IE (I'm using IE9, version 9.0.8112.16421), it says "File couldn't be downloaded" and the user is presented with a 'Retry' button. If they click Retry, it works fine. If they click Save, it works fine. In Firefox, it works fine.

How can I allow the user to open the file when the click Open the first time?

Pepper

Install fiddler and have it running when you make the first request. You will be able to inspect the response coming back from the server. Maybe that will shed some light on the issue. fiddler2.com/fiddler2 – Euthenics

@MattGrande did you get anywhere with this? I'm also having a similar problem, but with regular ASP.NET (no MVC involved) and CSV content type (not just XSL/XSLX). I found various sites with "solutions", but none of them seem to be very helpful... Same version of IE – Psychic

@LordScree - Unfortunately not. I was told that it was working well enough for the time being, and to come back to it later. What are the odds of that happening? Hahaha. – Pepper

@MattGrande I had interesting results as well in that, after the file fails to download, if you press "Open", it opens the actual rendered HTML source of the ASP.NET page (e.g. <html.../> etc.), as opposed to the CSV file, but if you press "Save" and then "Open", it correctly saves the CSV and opens it. I put that behaviour down to AJAX though, I reckon... still annoying. – Psychic

Late to the party, but has anyone been able to solve it this way? support.microsoft.com/en-us/kb/2549423 – Keenankeene

Answer 1

I was able to "trick" IE into doing the right thing by modifying the URL. It's kind of hacky, but here's the detail. HTH.

As a good MVC coder, I used Url.Action() to generate the right link in my view to my controller action. The result was "/Subscription/DownloadArchive", and I had the same issue. (I'm streaming a ZIP file down, but it seems no different than your CSV.) On a whim just now, after reading your post, I hard-coded the URL to "/Subscription/DownloadArchive/Archive.zip". I ignore the "Archive.zip" in code, but that is in fact the file name I return from my controller's action.

Presto!

Bort

Answer 2

I have the same problem and cannot offer a good solution (besides what Tood suggests, which is an option). But looking at the situation with fiddler & co., I have some more information that may be of help.

Our application is creating PDF documents on the fly and offering them as downloads. The issue is clearly data-dependent, meaning that some generated files download fine on the first attempt while others reproducibly need the retry.

Fiddler shows the server responses to be identical on each access, as far as I can tell. The requests differ, however (samples slightly edited):

First request:

GET http://localhost:12345/Item/PDF/id HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Referer: ...
Accept-Language: ...
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Accept-Encoding: gzip, deflate
Host: localhost:12345
Connection: Keep-Alive
Cookie: ASP.NET_SessionId=52znkt1fcisrolj44tnuyzu4

Second request:

GET http://localhost:12345/Item/PDF/id HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Host: localhost:12345
Connection: Keep-Alive
Cookie: ASP.NET_SessionId=52znkt1fcisrolj44tnuyzu4

Note, how the second request reduces the 'Accept:' header to just */*. The reason that I'm reluctant to add a file extension to the Url is that the suggested download name is generated from item data, submitted with the response and otherwise totally unrelated to the ID.

Cloudburst

Huh, that's very interesting. I'll have to come back to this and take a second look. – Pepper

I ran into the same issue with IE 11. I see the same results in Fiddler. My process was to open a text file from the local system and edit it or create one from scratch. The best workaround that I could come up with was to add a timestamp to the file name like filename.timestamp.txt and it worked fine after that. – Schuh

Answer 3

I had the same problem but if I changed the port number of Visual Studio Development Server to another, then this problem disappeared.

Cora

Answer 4

this works..

Response.Clear();
Response.ClearHeaders();
Response.ClearContent(); 
Server.ScriptTimeout = 3000;
Response.AppendHeader("Content-Disposition:", "attachment; filename=" + fileName);
Response.ContentType = "application/x-msdownload";
excelFile.SaveXls(Response.OutputStream);  
Response.Flush();
HttpContext.Current.ApplicationInstance.CompleteRequest();
// Response.Close();
Response.End();

Lorient