In our ASP.NET web site we have developed an aspx page that allows the user to download a file. The file path is sent as a parameter and then the file contents are read and written to the response stream. The code that we have used is the following:
string filepath = HttpContext.Current.Request.Params["FilePath"];
Response.Clear();
Response.ContentType = "application/octet-stream";
Response.AddHeader("Content-Disposition", "attachment; filename=" + Path.GetFileName(filepath));
Response.TransmitFile(filepath);
Response.Flush();
Everything works as expected in our development environment, but when we use this piece of code in our production server, we noticed that when trying to download almost all kind of files, nothing happens in the browser. It just opens a new window for that aspx page, but then it gets closed almost inmediately. It is very weird since we have tried downloading .pdf, .doc, .xls, .txt and image files with no luck, except with some (not all) .msg files.
We have being looking for a clue sniffing the HTTP traffic that reach to the browser with Fiddler, but we have seen nothing strange. In all cases the file contents are sent to the browser with no differences, so it seems that it is the browser doesn´t show the open/save/cancel dialog.
Here is a sample of the headers received in the browser with a failing file:
HTTP/1.1 200 OK Proxy-Connection:
Keep-Alive Connection: Keep-Alive
Content-Length: 421395 Via: 1.1
IBISA01 Date: Wed, 26 Jan 2011
12:02:54 GMT Content-Type:
application/octet-stream Server:
Microsoft-IIS/7.5 Cache-Control:
private Content-Disposition:
attachment;filename=P08-0656 Interflex
Especificación Inteface SGA ERP
Version 0.1.pdf X-AspNet-Version:
4.0.30319 X-Powered-By: ASP.NET
And these are the headers of a file that can be downloaded:
HTTP/1.1 200 OK Proxy-Connection:
Keep-Alive Connection: Keep-Alive
Content-Length: 290816 Via: 1.1
IBISA01 Date: Wed, 26 Jan 2011
12:03:29 GMT Content-Type:
application/octet-stream Server:
Microsoft-IIS/7.5 Cache-Control:
private Content-Disposition:
attachment;filename=Acalaracion final
Fichero ascii proveedores
Interflex.msg X-AspNet-Version:
4.0.30319 X-Powered-By: ASP.NET
In all cases, the full contents of the file appear after the headers with apparently no problems related to encoding.
We are wondering if there is some possibility to debug or trace the Internet Explorer activity to see why is rejecting to download the files.
The web server has Windows Server 2008 R2 and IIS 7.5. The browsers that we are using are IE 8.0 over Windows 7.
Many thanks in advance.
Jose Antonio Arroba
Finally we were able to see what was happening with this odd behavior in Internet Explorer when trying to download files. I forgot to mention that we were trying to download the file from a Silverlight app that calls an aspx page in charge of writing the file contents in its response. It seems that the security engine of Internet Explorer treats this behavior as an automatic download, and blocks it by default when browsing from a non intranet server.
Enabling the “Automatic prompting for file downloads” setting in the Internet Explorer Security settings for the Internet zone solved the problem. What still puzzles us is why before enabling this setting we were able to download some of the files.
Thank you very much to all who has tried to help us. Hope that this answer could save time to those who could experience this same bevavior in the future.
Best regards,
Jose Antonio Arroba