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)
Related
I know many people asks the opposite of what I am asking. I am trying to make browsers play the file instead of downloading when opening the mp3 files´ link. I do not care if the users download the file after that, but I need the browsers to play the file at first, instead of automatically downloading. It happens in computers and smarthphones.
, b
I don´t know if it is something I have to change in .htaccess file or somewhere else. The link to the site is this: https://cefadchurch.com/sermones/predicas-dominicales/
Try the download button. If you see, it directly sends you to the file´s link, but it starts downloading instead playing. I know a "Download" button function is obviously to make the browser download the file, but that will not be the case for me, because however, if the button sends me to the file´s link, I rather the browser play instead download, and the company has asked me for that function.
In your response headers, you're actively forcing the download in two ways:
Content-Disposition: attachment
Content-Type: application/octet-stream
Firstly, the Content-Disposition header value of attachment forces a download to occur. You must get rid of it if you want to not have a forced download.
Next, the content type of application/octet-stream is the generic binary type, and thus the browser doesn't know how to render it so just downloads it as a file to let the system handle it. If you're sending MP3s, use audio/mpeg for the Content-Type response header.
Finally, not all browsers can/will play media in a tab when you link to the media directly. If you want the file to play in-browser, you need to embed it into a web page with the <audio> tag.
I ve to servers with my project. I would like to understand why there is a difference in the behaviour on these 2. On the first one whne i click on:
OPEN
the new tab is opened with pdf being rendered and on the other server(the same browser - chrome) new tab is opened but instead of starting rendering pdf download window appears.
Thanks for any sugestions and explanation
the server is IIS 6.0
The one that is downloading the content does not have MIME types are not configured properly.
It is treating the files are unrecognized static files.
Since the Content-Disposition header is not set it properly, the browser doesn't know it can render those types.
Steps to configure MIME types
The two servers probably send the PDF file with different MIME types in the header, because they are configured differently. If you want PDFs to be opened in the browser, the correct MIME type is application/pdf, as defined in RFC 3778.
Here is a step-by-step tutorial on how to configure MIME types in IIS 6.0:
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/cd72c0dc-c5b8-42e4-96c2-b3c656f99ead.mspx?mfr=true
Seems like one of the browsers has a plugin available, or configured by mefor opening the document itself, while the other one doesn't (this might also mean that the MIME type of the file isn't properly configured so the browser doesn't know what to use to open the file).
If you want to force all browsers to show the download dialog (attachment) or trying to open it (inline), you can do so with the Content-Disposition header field. For instance:
Content-Disposition: attachment; filename="fileTitle.pdf"
or
Content-Disposition: inline;
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'm using Silverlight and I need to allow the user to save some dynamically genereated files.
For PDF files I created an http handler and it works just fine when I open it in a popup window.
For Excel files I tried every combination of Content-type and Content-disposition but IE8 refuses to open the file. With Fiddler I can see the get and there's a very short display of an IE window but it closes straight away.
I can't see any error message anywhere and I can't find any other description of the issue. IE7 exhibits the same behaviour.
I tried Content-type = application/vnd.ms-excel, application/unknown, application/octet-stream
and for for Content-disposition I tried inline and attachment.
PS: I can't use the SL built-in save dialog because it requires the context to be within a user action and I generate the file asychronously on the server.
Sounds like automatic prompting for downloads is disabled. See this description on how to enable automatic prompting. Enabling automatic prompting worked for me (situation: silverlight app uses Window.Navigate to open a popup to a generic handler that generates an excel file, with content-disposition: attachment, which worked fine in FF, but not in IE8).
As this post is already pretty old, I'm curious if you found a better way to solve this!
You should be using Content-Disposition: attachment
Have you tried on another client? My guess is maybe that Office is trying to get kicked off and is failing.
Alternatively, it's possibly related to http://blogs.msdn.com/ieinternals/archive/2009/10/02/Internet-Explorer-cannot-download-over-HTTPS-when-no-cache.aspx
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"