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.
Related
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)
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.
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.
we wrote CMS apps with asp.net. the user can attach file documents, pdfs to their forms and send to each other. the user can easily download the pdf and other documents but when they want to download jpg file their IE render the jpg file as a binary and show the binaries of jpg file? the IE didn't show the save as dialogue such as other files!
where is problem? and how can I handle this in asp.net? Is it relate to HTTPS? because the user used the https to connect to this cms.
As I understand it, users need to download the files and they are able to do so for some files but not for JPEG? And it shows as binary, what do you mean, it shows the byte codes?
Keep in mind each request has a content type header in the response which will identify to the browser what kind of content it is. This is set a known MIME type such as image/jpeg, ...
Content-Type: text/html; charset=utf-8
Browser loads each resource based on the content type. Having said that, it is up to the browser to load the resource the way it wants. I can personalise and change my browser setting to some point so you have to look at the user's browser if you cannot reproduce it on each machine.
In any case, you need to see the content-type header in the response for the resource (using Fiddler as someone else also suggested) and make sure it is set to a correct value. If it is set to image/jpeg, it will render it as image but if it is set to application/octet-stream it will download it. My hunch is it is set to something else (such as text/html or text/plain) and that is why browser tries to show it as a text.
I have a website where people can upload documents, and view them later at their convenience. I store the binary info along with the mime type in my db, and later just stream the binary content straight to the browser.
This works for for every file type except Office 2007 files. When I try to view the Office 2007 files, I get a popup requesting credentials. After I dismiss the the dialog (by canceling), I get another popup like the one below:
After also dismissing this dialog (by clicking "Yes"), the document finally opens. What gives? Does the browser really not know how to handle Office 2007 files? I checked the mime-type I'm saving, and everything looks correct. Any ideas on what I can do to get rid of these dialogs when trying to open a file?
Check out this explanation on VS Office Developer.
It gives a registry hack which your users could choose to apply to rid suppress this warning.
Your browser is probably not properly handling the Content-type and/or Content-Disposition headers properly. I've seen it happen in ff, safari and IE for various files presented in various ways.
Try downloading the file through an intercepting proxy (like webscarab or burpsuite) to see what the response headers look like. It should at least let you know if the problem is browser or server based.
Are you using content-disposition to set a filename as well? It might be an idea to try
Are you returning a "Content-Disposition" header with your streamed file? Also, keep in mind that Firefox and older versions of IE handle the filename header differently.
"Content-disposition: attachment; filename=movie.mpg"