i write and my page loads it find. When i click on the link instead of having the image show on screen it promps me to download it. Why? How can i make it display in the browser? gif and jpg both display in the browser.
-edit- i am using FireFox 3.5 there is no code that serves it, its just a link and the file exist in my folder. The link is like http://localhost:1737/a/b/file.png. IE 8 displays the png w/o making me download. I havent tried with other browsers but surely i click on direct png link in firefox on every site mine (in VS) should act the same.
If you're fetching it with HTTP, then there is a web server serving it. Look at the MIME-type when its returned, is that set correctly?
Telnet to localhost on port 1737 (not sure the syntax on Windows but IIRC try telnet localhost 1737) and type:
GET /a/b/file.png HTTP/1.0
Followed by two returns. Look at the Content-Type: field in the header. If it's not something like image/png you have a problem serving it. Firefox may have been guessing from the file name.
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)
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 have written the script in a .hta file and saved it on an apache server.
Then I hit the appropriate url stating the hta file.
In IE8 the file is executed and prompts for open, save, saveas.
But in Mozilla and chrome the content of the hta file is displayed in the browser
Have you configured the mime type for HTA correctly in Apache (it ought to be application/hta)?
IE 8 is probably compensating, but, Chrome and Firefox probably have no idea what it is. With the correct mime type being set in Apache, then, Chrome and Firefox will more likely react in the way you expect it to.
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"