I'm using the download href attribute to force the browser to download files. It works but in the case of png it does not:
<a class="esdc-AnchorBtn save" title="Download the image file in PNG format" href="http://csaint.esac.esa.int/ftp_public/jcook022221192/CSA_CG_PREGEN_6HOUR_jcook02_20181031_154434__20060111000000.png" download=""></a>
The image is rendered in the current browser window or a new tab if I add the target="_blank".
I guess this is happening because the Content-Type returned is "image/png"
Is there someway to force the browser to save the image.
Thanks
There are several things that could be going on.
But first, the download attribute only works under the following conditions;
This attribute only works for same-origin URLs. (ex: the page with the link must be on the domain csaint.esac.esa.int, as that is where hte link points to.)
Although HTTP(s) URLs need to be in the same-origin, blob: URLs and data: URLs are allowed so that content generated by JavaScript, such as pictures created in an image-editor Web app, can be downloaded. (In your case, is your page HTTPS?)
If the HTTP header Content-Disposition: gives a different filename than this attribute, the HTTP header takes priority over this attribute.
If Content-Disposition: is set to inline, Firefox prioritizes Content-Disposition, like the filename case, while Chrome prioritizes the download attribute.
In terms of your syntax, if you don't want to change the filename it should look like this:
<a [...] href='example.com/image.jpg' download></a>
If you want to change the filename, that is when you should set the attribute to have a value.
<a [...] href='example.com/image.jpg' download='myImage.jpg'></a>
When it comes to browser availability, it is pretty good. There are some that do not support it however, like IE. You can take a look at the details here: https://caniuse.com/#feat=download
Related
Update: I have concluded that this is a firefox issue. Chrome, Chromium Edge and Safari all work well with my solution. I have created a bug on the firefox bugtracker: https://bugzilla.mozilla.org/show_bug.cgi?id=1658877
I have a front-end that can download a file in 2 ways:
Click button 1 to open the file in the browser
Click button 2 to download the file to the hard drive
The way this works in the front-end is by using the <a download="FILENAME.EXTENSION"> tag and attribute for forcefully downloading the file, and to use <a> (without download) to make it open in the browser.
This works because the API never returns a content-disposition header (We use ASP.NET Core's File() method without the fileName parameter, which doesnt add a content-disposition header in this case) so the download attribute ensures it is downloaded.
Please read the background information before continuing
To try the fix the mentioned background information's issue, I changed our API to always return the following header for a file:
content-disposition: inline; filename=FILENAME.EXTENSION.
My idea is that the browser should open the file in the browser. if this is not possible, it will open a download pop-up and use the filename bit of the content-disposition header to give it a correct name. If it can open the file in the browser but the user pressed the download button, the <a download> should have higher priority and download.
The problem is that when using the <a download> way of downloading, that it STILL tries to open the file in the browser. I can understand why, but I would rather that it would respect the download attribute. I am using Firefox and the front-end and back-end run on the same domain!
Any clues?
For some background info:
We use ASP.NET Core 2.0. And if you use the built-in BaseController.File() method WITH the fileName parameter, it FORCES the attachment bit in a content-disposition header which makes it always download the file. We do not want that, so we used the variant of File() without specifiying a filename, which would not add a content-disposition header; this worked fine...
UNTIL we had to support MS word and MS excel files. When trying to use option 1, the user gets a pop-up like this:
As you can see, the filename is missing because the browser is not sending it in the content-disposition header. And I can't use the download attribute to specify it, because I pressed option 1 which means the file should be opened in the browser. If the file would be a PNG, it would then be forced to download.
At this point, I tried using inline;filename="FILENAME.EXTENSION as my content-disposition header, but this takes priority over the <a download> bit, defeating the purpose.
I can come up with 2 workarounds:
MS Word and MS Excel files must have a attachment bit in their content-disposition header so I can specify the filename and they download to disk, even if you tried opening it directly in browser.
But this isn't pretty; if some user would not have image/pdf support and downloaded an image or PDF file, my issue would still exist because the filename would be download again...
Have a download queryparam with the value 0 or 1 that specifies if the file should be downloaded with a INLINE or ATTACHMENT content-disposition header.
this might, compared to my current situation, be prettier, perhaps. but it is more work, and I wish that <a download> could just work.
I've created a simple img tag and set its src to a url as shown below:
<img className={"componentImageContainer thumbnailIcon"}
src="https://componentscendeveussa01.blob..../SVGLogo.svg" />
This method works fine for all filetypes (png, jpegs, jpgs, bmp) and I'm certain there is no issue in the rendering process as it shows the SVG perfectly if a local path is used. Also, there is no issue with the url because not only are they present in the database but also can be downloaded but putting the url in the browser address bar.
I have tried object tag, setting source via backround-image property in css and checking the content-type that is set in the response headers. It is of type application/octet-stream (same as all other file types). What could then be the reason that a broken image is shown whenever an SVG is fetched.
I think you need to outline the svg and upload it. I had the same issue. The font in the svg was not working in the url. So I outlined the svg in Illustrator. Worked fine.
When clicking a PDF link in Firefox and Chrome, the file will sometimes be opened for in-browser viewing and sometimes prompt a "Save as" dialog.
If I wanted to force the link to always prompt a download I could use the download HTML5 attribute.
However, I want to do the opposite. I.e., force the links to always be viewed in the browser.
Sort of an inverse download attribute. Is there such a thing? :)
I'd prefer to not modify response headers when serving PDF documents - I want to be able to specify in markup what the browser behavior should be.
Thanks!
You can achieve that by setting the appropriate header (for instance, in case of PDF, the header will be Content-type: application/pdf;
With this header, the browser will know the mime-type of the file and display it if it is compatible with it.
Here you can see the headers for a PDF.
As a hint, what I like to do is to use some sort of controller (in case you are using a backend language) that handles the download. Hence, to download myNewProject.pdf I do
<a href='download.php?file=myNewProject.pdf&viewInBrowser=1'>Download!</a>
Then I can set the appropriate headers depending on the file type, or if I want to force download or view it in the browser...
I'm using Firefox in XP. I went to the OPTIONS under Tools and found Portable Document Format. Click on it and it will allow you to change the way PDF files are handled.
open the file in a Microsoft Word and save as html.
A client wants a url to be a download link.
Use case is like so:
user gets linked to example.com/download once there, it downloads a pdf file.
Can I do this without php ?
HTML5 introduced the download attribute.
Supporting user-agents will offer to download the file foo.png when clicking this link:
<a href="foo.png" download>Save the image</a>
You can also specify a different default file name that should be used:
<a href="foo.png" download="image.png>Save the image</a>
Read more at http://www.w3.org/TR/html5/links.html#downloading-resources.
Note that this only works for links. When users enter the URL directly into their browsers, this will have no effect, of course. If you want that, you need to send specific HTTP headers. See for example the question: How to force download of a file?. You don’t necessarily need a programming language like PHP for that. You can do it with, for example, .htaccess, too: Force File(image) Download with .htaccess
How a file is displayed is browser specific. Some may force you to download while some directly render it on the browser.
If you want to force the browser to download the file then you can set in Header the
Content-Type : application/octet-stream
You only need a link (anchor tag). The way the link behaves on click will depend on what browser you are and what settings you have in that particular browser. Some browsers will prompt you to open or save the file, other browsers will open the PDF file on a new tab or window.
Download PDF
You'll also need to make sure that the path to the PDF file is correct on the href property of your anchor tag.
Use this (HTML) not PHP:
Download pdf
Use the full url including the pdf file like.
Download
I have an anchor tag that is used to request the download of a file.
Like this:
Download
The file may be modified on the server very often, so I want to make sure the browser does not cache the file.
However, testers found out that, although it seems to always download the file when you click on the link, when you right-click on the link and choose "Save As...", the browser seems to choose to use the cached file instead. This was tested with IE9.
How can I force the browser (especially IE9) to always download the file in every case?
I'll add as an answer. Try adding a random number to the query part of the href:
?param=[random]
As per my own comment for one of the answers:
According to wikipedia I can set the response header parameter: Cache-Control: no-cache
http://en.wikipedia.org/wiki/List_of_HTTP_header_fields#Effects_of_selected_HTTP_header_fields
After receiving a response with this header, the browser will not cache this data anymore.