I'm trying to download an excel file (generated dynamically using C#\ASP.NET) and I get the IE10 View Downloads dialog when I click "Open" it says "abc.xls couldn't be downloaded" error but after clicking "Retry" it opens the .xls file properly in the second try.
When I test this in Firefox or Chrome it works fine.
I think this may explain the strange behaviour:
"Content-Length and Transfer-Encoding Validation in the IE10 Download Manager"
It seems that IE9 beta had introduced content-length and transfer-encoding validation when downloading files, but found it was too problematic since many servers didn't send proper values for these downloads that are processed through code. Apparently they turned it back on in IE10 however and just hoped for the best.
I'd wager that accurate values being sent when the download is started should clear up this problem. Of course, it shouldn't have been a problem to begin with... ai yi yi.
[Edit]
Turns out this problem was related (for me at least) with using Response.Close() and/or Response.End() in code. This article explains why you shouldn't use these 2 methods, and why HttpApplication.CompleteRequest is the method of choice. Changing our Response.End() and Response.Close() instances to HttpApplication.CompleteRequest solved our IE10 download issues. Like magic. Apparently MSDN now discourages use of these 2 methods (despite years of MSDN code examples containing them), and now advocates use of HttpApplication.CompleteRequest instead.
We were always at war with Eurasia...
[/Edit]
I was getting a similar behavior -
After fighting this issue for about 12 hours what worked for me:
Changing response header from
Content-Type: application/application/vnd.ms-excel
To
Content-Type: application/octet-stream
Note that I had another an unmentioned symptom: I was setting
Content-Disposition: attachment; filename="Inventory_10-10-2013.xls"
Despite that setting IE used the file name from the URL (so it said "getInventory couldn't be downloaded" - and it saved the wrongly named file in the downloads folder!).
When I changed the 'Content-Type' IE started honoring the file name from the header.
For the record here are all the response headers that I'm setting:
HTTP/1.1 200 OK
Pragma: Public
Expires: Fri, 11 Oct 2013 16:33:38 GMT
Cache-Control: max-age=1
Content-Disposition: attachment; filename="Inventory_10-10-2013.xls"
Content-Transfer-Encoding: BINARY
Set-Cookie: fileDownload=true; path=/
Content-Type: application/octet-stream;charset=UTF-8
Content-Length: 7680
Date: Thu, 10 Oct 2013 16:33:38 GMT
Related
I have a classic ASP application with a page that will export a CSV file. It works in all browsers except Internet Explorer (IE). It worked in IE before the company updated everyone's computer to Windows 8 and IE10. I've tried compatibility mode on and off and I have used F12 to change the Browser Mode and Document Mode. I have the following code to set headers and etc...
Response.ContentType = "application/csv"
Response.AddHeader "Cache-Control", "no-cache"
Response.AddHeader "Content-Disposition", "attachment; filename=myfilename.csv"
I've also tried Response.Content-Type="text/csv" with no success. I've been banging Google hard for a day or two looking for resolutions but cannot find any help. Does anyone have some suggestions?
EDIT: Below is some more information I've pulled from Fiddler about the headers. Also, I should have mentioned that Fiddler shows the data is being written to the Response.
HTTP/1.1 200 OK
Cache-Control: no-store, no-cache,private
Content-Type: text/csv
Server: Microsoft-IIS/7.5
Content-Disposition: attachment; filename=somefilename.csv
Persistent-Auth: true
X-Powered-By: ASP.NET
Date: Thu, 14 Aug 2014 17:41:56 GMT
Connection: close
UPDATE:
I've been able to determine the issue is occurring due to the fact I am uploading a file and then trying to export file in the same Request/Response cycle. When I submit the data manually (via hidden fields) and not upload the file, the download works. So now I am trying to figure out a fix for this situation.
RESOLVED
It turns out to be an Internet Explore plus Windows Update issue. See the link below for more information.
Problem Description
When doing updates to accounts in CRM 4.0, the preview does not update unless we clear the client cache. When requesting the preview (which happens when you click the little arrow shown in the screenshot) with URL shown below, the headers shown below are returned.
GET http://crmdev/DevOrg/_grid/preview.aspx?type=1&id={755E4F74-007D-E011-A3BC-005056B6001D} HTTP/1.1
As can be seen from the headers, there is no expiration date/time on the cache.
HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 1006
Content-Type: text/xml; charset=utf-8
Server: Microsoft-IIS/7.5
X-AspNet-Version: 2.0.50727
Persistent-Auth: false
X-Powered-By: ASP.NET
WWW-Authenticate: Negotiate <token removed>
Date: Tue, 19 Jul 2011 13:35:10 GMT
Setting the cache to expire using the method described in the following link has no effect. http://www.iis.net/ConfigReference/system.webServer/staticContent/clientCache
Does anyone have a supported fix for Dynamics CRM 4.0 regarding the caching of the preview.aspx page? Almost all other examined pages in CRM returns 'Cache-Control: no-cache', so seemingly this file overrides the output header.
ADDITIONAL INFO ADDED
This behavior only affects IE9. Either IE9 is handling the caching unlike IE8 and before or IE9 is not allowing the corss tab/popup cache invalidation.
Suggested hotfix (unsupported): Replace preview.aspx with a custom aspx file that uses the original renamed file and has manual control over the cache header. Setting the cache-header to 'no-cache' solves this issue in IE9. We have opted out of this solution as it is unsupported, but it has been tested ok and requires no altering of aspx-content, only "rerouting".
This behavior only affects IE9. Either IE9 is handling the caching unlike IE8 and before or IE9 is not allowing the cross tab/popup cache invalidation.
Suggested hotfix (unsupported): Replace preview.aspx with a custom aspx file that uses the original renamed file and has manual control over the cache header. Setting the cache-header to 'no-cache' solves this issue in IE9. We have opted out of this solution as it is unsupported, but it has been tested ok and requires no altering of aspx-content, only "rerouting".
I have a rendered HTML page that I am exporting to MS Word and downloading on a button click.
Here is the code snippet in the button click.
` Me.EnableViewState = False
Response.ContentType = "application/vnd.ms-word"
Response.AddHeader("Content-Disposition", "attachments;filename=XXXXXXX.doc")
Response.Buffer = True
Response.BufferOutput = True`
The functionality works perfectly well in Firefox & IE when I checked in system testing environment (locally). However when it was moved on to the hosting server (production environment) the functionality is not working in IE but is still working perfectly in Firefox.
I am not sure on where to check for the exact issue. Could it be a caching related problem?
In IE it is just not opening the download window which we will obtain when the rendered HTML content type is changed and the response stream is flushed. No exception is thrown.
I received the following response header:
HTTP/1.0 200 OK
Cache-Control: private
Content-Length: 15189
Content-Type: application/vnd.ms-word;
charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 2.0.50727
Content-Disposition: attachments;filename=NewAccountForm.doc X-Powered-By: ASP.NET
Date: Fri, 18 Mar 2011 10:18:07 GMT X-Cache: MISS from Gateway X-Cache-Lookup: MISS from Gateway:808 Via: 1.0 Gateway (squid/3.0.STABLE10) Proxy-Connection: keep-alive
Is your hosted environment adding http headers? IIS could easily be configured to add headers that are messing up what you want to send out. It's actually quite common, and could be the issue. You'll need to determine this for sure, so here's a suggestion for investigating:
Try using a WebClient class and look at the Response headers.
Edit - updated
I just noticed - did you remember to put
Response.Clear();
before adding headers? It may not be the hosting environment at all. However, given that it works locally and not at your hosting environment, and assming that it is the same code, it still looks to me like something is different about the hosted environment, and the most logical option would be the headers.
I set Response.Charset = "" and always do Response.Flush(), Response.End(), and Response.Close() after I export the HTML.
This is just making me angry. I can't figure out why all the resources in my page are being requested EVERY single time.
E.g. my site.css returns the following headers (using fiddler):
HTTP/1.1 200 OK
Server: ASP.NET Development Server/9.0.0.0
Date: Mon, 29 Nov 2010 17:36:21 GMT
X-AspNet-Version: 2.0.50727
Content-Length: 9093
Cache-Control: public, max-age=2592000
Expires: Wed, 29 Dec 2010 17:36:21 GMT
Last-Modified: Mon, 08 Nov 2010 17:20:16 GMT
Content-Type: text/css
Connection: Close
But every time I hit refresh I see all the resources (css,js,images) getting re-requested. I have control over the headers returned for any and all of these resources, but I haven't figured it out yet.
I have even debugged my ASP.NET app and the HttpModule is definitely being asked for the resources again.
Can someone give me an idea of what to do?
EDIT:
Ok, I removed must-revalidate, proxy-revalidate from the headers and that is getting me closer to where I want to be, now when I press back it still requests my css/js files when I press back.
Is there anything more I can do to avoid this?
The following links might be of help to you.
Differences in reload behavior between FF and IE
http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firefox-and-ie-caching/
In a nutshell, your caching behavior is going to be determined by the headers and the browser you are using.
What browser are you using for testing? The back button is also handled differently.
Back Button (Browser Behavior)
And, finally, a breakdown of f5/ctrl f5, click, shift click, etc behavior between browsers:
What requests do browsers' "F5" and "Ctrl + F5" refreshes generate?
If you are handling the requests in your own module - which seems to be the case - and the request contains an If-Modified-Since header, you can use that to determine whether to respond with a 200 and sending the whole resource again, or just send a 304 and skip sending the js/css/etc contents.
Other than that, expect browsers to re-query resources on hitting F5 / Refresh. It is just that you may skip sending the whole js/css/etc and return a 304 if everything is OK.
Other than that, #Chris's answer covers pretty much everything else.
What are the request headers you see when you hit back?
Use case: user clicks the link on a webpage - boom! load of files sitting in his folder.
I tried to pack files using multipart/mixed message, but it seems to work only for Firefox
This is how my response looks like:
HTTP/1.0 200 OK
Connection: close
Date: Wed, 24 Jun 2009 23:41:40 GMT
Content-Type: multipart/mixed;boundary=AMZ90RFX875LKMFasdf09DDFF3
Client-Date: Wed, 24 Jun 2009 23:41:40 GMT
Client-Peer: 127.0.0.1:3000
Client-Response-Num: 1
MIME-Version: 1.0
Status: 200
--AMZ90RFX875LKMFasdf09DDFF3
Content-type: image/jpeg
Content-transfer-encoding: binary
Content-disposition: attachment; filename="001.jpg"
<< here goes binary data >>--AMZ90RFX875LKMFasdf09DDFF3
Content-type: image/jpeg
Content-transfer-encoding: binary
Content-disposition: attachment; filename="002.jpg"
<< here goes binary data >>--AMZ90RFX875LKMFasdf09DDFF3
--AMZ90RFX875LKMFasdf09DDFF3--
Thank you
P.S. No, zipping files is not an option
Zipping is the only option that will have consistent result on all browsers. If it's not an option because you don't know zips can be generated dynamically, well, they can. If it's not an option because you have a grudge against zip files, well..
MIME/multipart is for email messages and/or POST transmission to the HTTP server. It was never intended to be received and parsed on the client side of a HTTP transaction. Some browsers do implement it, some others don't.
As another alternative, you could have a JavaScript script opening windows downloading the individual files. Or a Java Applet (requires Java Runtimes on the machines, if it's an enterprise application, that shouldn't be a problem [as the NetAdmin can deploy it on the workstations]) that would download the files in a directory of the user's choice.
Remember doing this >10 years ago in the netscape 4 days. It used boundaries like what your doing and didn't work at all with other browsers at that time.
While it does not answer your question HTTP 1.1 supports request pipelining so that at least the same TCP connection can be reused to download multiple images.
You can use base64 encoding to embed an (very small) image into a HTML document, however from a browser/server standpoint, you're technically still sending only 1 document. Maybe this is what you intend to do?
Embedd Images into HTML using Base64
EDIT: i just realized that most methods i found in my google search only support firefox, and not iE.
You could make a json with multiple data urls.
Eg:
{
"stamp.png": "data:image/png;base64,...",
"document.pdf": "data:application/pdf;base64,..."
}
(extending trinalbadger587's answer)
You could return an html with multiple clickable, downloadable, inplace data links:
<html>
<body>
<a download="yourCoolFilename.png" href="data:image/png;base64,...">PNG</a>
<a download="theFileGetsSavedWithThisName.pdf" href="data:application/pdf;base64,...">PDF</a>
</body>
</html>