Internet Explorer error using Asp MVC 4.0 FileResult

Question

I have the following code, deployed on a https Asp site, build with MVC 4.0:

public FileResult ANotSoWorkingFunction(string filePath, string fileName)
{
 pathToFile = string.Format("~/{0}/{1}", pathToFile, fileName);
 return File(new FileStream(pathToFile, FileMode.Open), "application/pdf", fileName);
}

This will work (as you many of you probably already guessed) with Chrome, Firefox and IE9. But it will throw a:

---------------------------
Windows Internet Explorer
---------------------------
Internet Explorer cannot download someFileName from a_site.com.


Internet Explorer was not able to open this Internet site.  The requested site is either unavailable or cannot be found.  Please try again later.
---------------------------
OK   
---------------------------

On IE6,7,8

Any ideas or clues on this one are greatly appreciated as I already spend the hole day playing with html header.

EDIT:

Here are the header from IE7:

HTTP/1.1 200 OK
Cache-Control: private, no-cache="Set-Cookie"
Content-Type: application/pdf
Server: Microsoft-IIS/7.5
X-AspNetMvc-Version: 4.0
X-AspNet-Version: 4.0.30319
Set-Cookie: .ASPXAUTH=; expires=Mon, 11-Oct-1999 21:00:00 GMT; path=/; HttpOnly
X-Powered-By: ASP.NET
Date: Wed, 04 Apr 2012 08:43:50 GMT
Content-Length: 233324

And here are the ones from IE9:

HTTP/1.1 200 OK
Cache-Control: private, no-cache="Set-Cookie"
Content-Type: application/pdf
Server: Microsoft-IIS/7.5
X-AspNetMvc-Version: 4.0
X-AspNet-Version: 4.0.30319
Set-Cookie: .ASPXAUTH=; expires=Mon, 11-Oct-1999 21:00:00 GMT; path=/; HttpOnly
X-Powered-By: ASP.NET
Date: Wed, 04 Apr 2012 08:42:14 GMT
Content-Length: 233324

Thank you,

Answer 1

I think I also ran into your problem.

I am also running IIS 7.5 and downloading a PDF through an action on an HTTPS request. For reasons I have yet to isolate, IIS 7.5 seems to be appending no-cache="Set-Cookie" to my Cache-Control response header regardless of what I set the Cache settings to on the Response. This was causing the fairly well documented no-cache issue on IE6, IE7, and IE8.

To resolve this, I made a small wrapper around the FileContentResult that cleared the headers, called the parent, then set the Cacheability to 'Private'. This side-stepped IIS 7.5's insistence to add no-cache="Set-Cookie" to the header, and the file downloaded properly in all browsers I tested. If you want to emulate what I did, first, here's my FileContentResult wrapper.

public class PdfContentResult : FileContentResult {

    public PdfContentResult(byte[] data) : base(data, "application/pdf") { }

    public PdfContentResult(byte[] data, string fileName) : this(data) {
        if (fileName == null) {
            throw new ArgumentNullException("fileName");
        }

        this.FileDownloadName = fileName;
    }

    public override void ExecuteResult(ControllerContext context) {
        context.HttpContext.Response.ClearHeaders();

        base.ExecuteResult(context);

        context.HttpContext.Response.Cache.SetCacheability(HttpCacheability.Private);
    }
}

Then I added an extension method to my ControllerExtensions so that it would be simple to find:

public static class ControllerExtensions {

    public static PdfContentResult Pdf(this Controller controller, byte[] fileContents, string fileName) {
        return new PdfContentResult(fileContents, fileName);
    }

}

Finally, within the Action, I did the equivalent of this:

public ActionResult MyGeneratedPdf() {
    byte[] myPdfContentInByteStream = GetPdfFromModel();
    return this.Pdf(myPdfContentInByteStream, "MyFile.pdf");
}

Obviously, if you're downloading all kinds of data types, you might not want to bind the workaround so closely to PDF.

Answer 2

We resolved this by changing the cache-control header before streaming the file.

Simplified code sample:

var browserInformation = Request.Browser;

//Set as private if current browser type is IE
Response.AppendHeader("cache-control", 
                    browserInformation.Browser == "IE" ? "private" : "no-cache");

return File(fileName, contentType, downloadFileName);

This worked (yay).. BUT I was left with a lack of clarity on why we had to do it this way for that specific site. We have four websites running on the same box, all under SSL, and only one had this header problem. I compared the web.config files and looked at the setup in IIS but couldn't shed any further light on why that one site needs those headers set explicitly.

If anyone has more to add on the above (for added clairty) that would be great.