After recent system updates, can no longer download files in IE 11 - asp.net

Sometime in the last few weeks, MS pushed out IE 11 updates on Windows 10 which I believe may be interfering with the ability to download Excel and PDF files inside an iframe in my ASP.NET web application.
This issue applies only to certain versions of IE 11 (my machine is on 11.192.16299.0) on Windows 10. It has not been reported to with other Windows versions. Machines operating with certain older versions of IE 11 apparently do not experience the issue.
My application has an iframe, in which my own content can be loaded. After loading a page into the iframe and attempting a file download within that iframe, it appears to the user that nothing happens. Inspecting the console, I notice the following two warnings, which have been present in the application for quite some time:
SEC7131: Security of a sandboxed iframe is potentially compromised by allowing script and same origin access.
DOM7011: The code on this page disabled back and forward caching. For more information, see: http://go.microsoft.com/fwlink/?LinkID=291337
Inspecting network traffic, I can see the file request go out, and a response come back. The response has the following headers:
Cache-Control: no-cache, no-store
Content-Disposition: attachment; filename=doc.pdf
Content-Length: 97542
Content-Type: application/pdf
Date: Thu, 25 Jan 2018 18:27:37 GMT
Expires: -1
Pragma: no-cache
Server: Microsoft-IIS/10.0
X-UA-Compatible: IE=Edge
This appears to be a normal request to me. Cache-Control is properly set to no-cache, as the document contents are dynamically generated.
And finally, here is the code in my codebehind that initiates the file download for a PDF:
Public Sub DownloadPdf() Handles Pdf.Click
Dim pdf As Byte() = GetPdf()
With Response
.Clear()
.ClearHeaders()
With .Cache
.SetCacheability(HttpCacheability.NoCache)
.SetNoStore()
.SetExpires(Date.UtcNow.AddHours(-1))
.SetMaxAge(New TimeSpan(0, 0, 30))
End With
.ContentType = "application/pdf"
.AddHeader("Content-Disposition", "attachment; filename=doc.pdf")
.AddHeader("Content-Length", pdf.Length.ToString)
.BinaryWrite(pdf)
.Flush()
.End()
End With
End Sub
The Excel download code is quite similar. It is fair to assume GetPdf() is working properly, as the PDF generates and downloads in other browsers (Edge, Chrome, Firefox).
I have inspected IE settings for the Internet and Local intranet security zones, and the configuration appears to be normal. File downloads are allowed, plugins are allowed to run (or require prompt in some cases). I even attempted to loosen security settings across the board to determine what may be causing my issue, but I had no luck. In the dev console, I set the debugger to break on all exceptions, but no exception is being thrown during the file download process.
I can view PDFs from other websites and download files, but it seems that most of the test sites I found are serving static content. On the other hand, my files are created on the fly and the download process seems to function a bit differently.
Are there any apparent issues with my setup? Were there any security or settings changes that accompanied recent MS updates that could be interfering with my application? I appreciate any and all help with this. Thanks for looking.

In certain Windows 10 builds (confirmed for 1703 and 1709), IE security settings were changed to prevent sandboxed iframe file downloads. There is no settings change or workaround I discovered that can resolve this other than removing sandboxing from the iframe.

Related

Firefox 84.0 is changing custom file extension from downloaded file

My web application creates a zip file to download files related to a "Task" instance. This zip file can contain images, .pdf or .txt files, the filename created has the form "{taskName}.taskBundle".
To download the file, the web application use the following headers in the response (from Firefox Network monitor):
Content-Disposition: attachment; filename="task1.taskBundle"
Content-Type: application/zip;charset=UTF-8
The problem:
Using Firefox 84.0 (Ubuntu and Windows versions), the browser is replacing the '.taskBundle' extension by '.zip', so the downloaded filename is "task1.zip" instead of "task1.taskBundle".
I tried to download the same file with Chrome (87.0) and another Firefox versions (83.0, 82.0, 80.0, 74.0) and the file name is correct: "task1.taskBundle".
Maybe should I add another header to the response to prevent Firefox change the file extension?
I can change the Content-Type to 'application/octet-stream' but the checkbox "Do this automatically for files like this from now on." is not displayed in the download dialog.
Additional notes:
My app is written using Grails 3.3.9 but I think it is not a Grails issue because the response headers are sent to the client as described before.
We're fixing this in https://bugzilla.mozilla.org/show_bug.cgi?id=1684183 , but it'll likely not be before Firefox 85 (ie we won't be shipping a security / out-of-cycle dot-release fix just to address this issue).
A simpler workaround for your usecase would be choosing / standardizing on a specific mimetype for these "task bundles", along the lines of application/x-my-fancy-application-task-bundle, if you don't want the UA to treat it as a zip file.
Both Firefox and other browsers can decide to act on the mimetype (e.g. in Firefox's case, we show "Open in Firefox" options if you send application/pdf or SVG mimetypes, even for Content-Disposition: attachment responses, to simplify opening the content immediately). Chrome has specific checks for application/zip when sniffing.
The regressing change here was part of a fix to handling web servers who send foo.jpg files with Content-Type: image/webp, where users complained that the resulting .jpg files were not, in fact, jpegs. So we added extension normalization for a number of different mimetypes. I mistakenly assumed that application/zip files would be, you know, zip files, and could be treated as such.
You might want to report this on Mozilla's Bugzilla site (https://bugzilla.mozilla.org) under Firefox as I can't find a report that describes this exact behavior. It looks like they've broken something in the latest version (whether it was a bug or a feature is hard to say) as I noticed this behavior on a site with a mismatching Content-Type too.
Of course, if it was an intentional change, it wouldn't be the first time the Mozilla has ignored web standards to do things "their way". It still annoys me to no end that I have to use the 5-slash hack to get file protocol links to open correctly when the standards clearly state otherwise (see: https://bugzilla.mozilla.org/show_bug.cgi?id=992123)

Azure storage download on IE9 changes the file extention to ZIP

I allow users to download files from a Windows Azure storage pool by using SAS (cf. this discussion). The SAS is being constructed and next the Request.Redirect(targetURL) is called to redirect the client's browser to download the file.
This works well using Chrome to download a file (a proprietary binary file ending on the extention .dp).
However, when downloading the same file (using the same URL) on Internet Explorer 9, the extension of the file is being changed to .zip (removing the original .dp).... Some users still use IE9 :(
I've checked the content-type of the blob, which is application/octet-stream (and hence should be correct).
Why does IE9 changes the extention of the file and what can I do to prevent this?
Do I need to instruct Azure to leave the .dp file as-is (mime-type wise) and if so, how can I configure that?
edit: I really want to use redirection and not blob.openread()/response.write() to avoid additional load on the webserver.
Update 1
I've used Fiddler to see the server answer on the download request, and it is clear that the content-type is correct:
HTTP/1.1 200 OK
Content-Length: 60783
Content-Type: application/octet-stream
Last-Modified: Fri, 17 Aug 2012 13:25:24 GMT
ETag: 0x8CF4XXXE4DD2184
Server: Blob Service Version 1.0 Microsoft-HTTPAPI/2.0
x-ms-request-id: 21XXXXX-9e42-4ca8-a425-e84269d9f104
Date: Fri, 17 Aug 2012 16:49:05 GMT
The content payload of the server starts with
PK����nAQ������p����
* FIDDLER: RawDisplay truncated at 128 characters. Right-click to disable truncation. *
Does IE interprets the "PK" as PKZIP and hence beliefs it's a ZIP file?
How can this be disable (on the client side) - cf. first comment below was not the trick...
Kind regards,
Robbie De Sutter
I suspect this is just IE doing something annoying. I'd suggest changing the content type to something like application/x-foobar, maybe replacing "foobar" with something more meaningful. :-)
I haven't tested it, but I would think that's sufficient to get IE to stop trying to guess the file type.
You can trick IE by adding a query string parameter at the end, something like: &ext=.exe.
We generate a link to .exe + sas token. So, the link is accessible for a short period of time. IE can't figure out that file https://.blob.core.windows.net/container/file.exe?sv=2014-02-14&sr=b&sig=1oRgEzi%2F5uXCPUiseHizadfadfasdfa0vEs%3D&st=2015-05-18T19%3A36%3A42Z&se=2015-05-18T19%3A46%3A42Z&sp=r is actually an executable and saves it with no file extension. But if I do:
https://.blob.core.windows.net/container/file.exe?sv=2014-02-14&sr=b&sig=1oRgEzi%2F5uXCPUiseHizadfadfasdfa0vEs%3D&st=2015-05-18T19%3A36%3A42Z&se=2015-05-18T19%3A46%3A42Z&sp=r&ext=.exe (adding &ext=.exe at the end) IE now saves the file appropriately.

force cache to update in IE browser with a request - C#, ASP

I am working on a webapplication where users can login into their accounts and change settings for their accounts. If they make changes there, let us color for their account it will be modified in the css file and the new css should be applied for their account. But it is not doing that one since css file has been cached. I am using on IIS 7, C#, ASP.Net, IE 9 browser.
Can any help me on this issue.
I'm guessing that the css file is generated by some server side script,
because you didn't told what language you use, i'll example with PHP.
Well what you need is to send headers of cache control to the browser, so it won't save any cache on the css file, if you use PHP this is the code that you need to use:
<?php
header("Cache-Control: no-cache, must-revalidate"); // HTTP/1.1
header("Expires: Sat, 26 Jul 1997 05:00:00 GMT"); // Date in the past
?>
Remember to call the header functions before you send any data to the browser.
Hope that solved your problem.
Have the server render the page with a version string embedded in the path. For example:
httpx://www.yourdomain.com/css/12345/customized.css
Whenever the user modifies a setting in the CSS file, update the version and have new pages the user requests reference the new version.

How to setup Silverlight xap caching to work the same in all browsers

Basic Requirements
I have a SL app that can be run in-browser or out-of-browser. I want the browser to:
Cache the xap file
Load the xap from the cache if it has not changed or re-download it if it has changed.
More details
Setting a future expires header obviously solves the caching problem but then I cannot force the user to download the latest version. Normally I would just add a querystring to the url (eg url?v=1) but I cannot do this as this breaks the out-of-browser functionality. eg the app thinks it is not installed when in fact it is.
no cache
If I set Cache-Control to no-cache, Chrome and Firefox correctly send a request to the server for the xap but use the cache if a 304 is returned. IE8 just downloads the file again as does Safari.
must-revalidate
Setting Cache-Control to must-revalidate again works correctly in Chrome and Firefox but Safari always downloads the xap again while IE8 always uses the cache.
How do I set this up to work as described at the start of this question?
I'm not sure that the Chrome/Firefox is strictly "correct", you have after all not told the browser that it should cache the content or even that the content is cacheable.
Instead of no-cache try "Cache-Control: max-age=15" instead. See if that convinces IE that it ought cache the content despite its large size (which is why its not caching it originally).
For OOB install use the Application object's CheckAndDownloadUpdateAsync method. Note you need to inform the user to restart the app once an update has been downloaded.

Download file over HTTPS in IE 5.5 / IIS 5.0

I desperately need help with this one. I have a classic ASP website in IIS 5, where I need to stream pdf to users. I am using ADODB.Stream to generate chunks of binary data and using response.BinaryWrite to stream it to client. Now problem is that there is a known feature in IE which sets the Response CacheControl header to "no-cache" by default for SSL (https) sites. Hence I am getting the standard error:
"Internet Explorer cannot download File.doc from ServerName.
Internet Explorer was not able to open this Internet Site. The requested site is either unavailable or cannot be found. Please try again later."
I have set Response.CacheControl = "private,must-revalidate,max-age=3600" before streaming, but it still give the error.
Note: The same code works perfectly in all other browsers like firefox and netscape.I am using LiveHttpHeaders in firefox to see that Response.CacheControl is automatically set correctly in firefox. Unfortunately i cannot install Fiddler on my machine, but i am guessing problem is due to IIS default header CacheControl = "no-cache" for https
I have unchecked the "Do not save encrypted pages to disk" option in IE.
I need a way around this since the option has to be made available very soon to users over the internet with existing technology :(
Start here: http://blogs.msdn.com/ieinternals/archive/2009/10/02/Internet-Explorer-cannot-download-over-HTTPS-when-no-cache.aspx to see a fuller discussion of this issue. It's quite likely that you're sending one or more headers that forbid caching.
The statement...
there is a known feature in IE which
sets the Response CacheControl header
to "no-cache" by default for SSL
(https) sites
... is incorrect. Did you mean to say "IIS"? Which version? I've never heard of such a feature.
I don't know why you can't use Fiddler on the machine in question?
maybe this could help:
Link
I solved a similar problem checking "enable content expiration" on the http headers tab of the iis management console.
You might be able to get away with dropping support for Internet Explorer 5.5 as it has less than .5% of the market. It so low they stopped tracking it on in jun 08'

Resources