View Full Version : Force Download with .htaccess
I've been trying to find a way of force downloading mp3's for an internet radio website and stumbled accross the .htaccess method using:
Header set Content-Disposition attachment
AddType application/octet-stream mp3
Both seem to work fine for most mp3's but for some strange reason not all of them. I had tried renaming the files that dont work with names that do, to no avail and it is not size dependand as some of the files that don't work are smaller than ones that do. As far as I can tell there is no difference between the files that do and do not work and are all in the same folder.
Any ideas anyone....:confused:
You're probably using IE. IE attempts to second-guess the server as to the downloaded file's MIME-type. There is, unfortunately, nothing that can be done about this.
Not possible, I'm afraid.
Your best bet is to compress it somehow (gzip, bzip2, zip).
03-27-2006, 02:13 AM
so... downloading as opposed to streaming?
Isn't there some way to make it automatically download?
Not FORCED download... as in they can still type in the url into the address bar, but it would make it default to downloading.
03-27-2006, 07:20 AM
No, I just meant making it open as a download as opposed to a link you can just click and go to. Not sure how to do it... gmail does it with certain filetypes... there's some way, but might be incredibly complex CGI or something, or something more than that.
That'll work, though. Yep.
Hmmm, interesting. Care to elaborate?
03-27-2006, 11:09 AM
No, I just meant making it open as a download as opposed to a link you can just click and go to. Not sure how to do it... gmail does it with certain filetypes... there's some way, but might be incredibly complex CGI or something, or something more than that.No, what the OP originally posted is about the best that can be done from the server.
If IE didn't have a complete disregard for the requirements of RFC 2616 (that is, HTTP/1.1), this wouldn't be an issue (and this is the biggest stumbling block). Simply presenting an application/octet-stream Content-Type header value would produce the download prompt. Allowing the user to configure content handling, like Opera and Firefox permit, would result in an even better solution: send an accurate Content-Type header value and act based on user preferences.
I'm afraid there isn't really what you'd consider an adequate solution; trying to force anything on the Web is often a non-starter. Suggestions are about as much as you can hope for, and poor software, like IE, will always limit your options.
I would be happy if I could at least get a dialogue asking the user what they would like to do with the file. There are some instances when you would prefer to stream large mp3's for instance if you just wanted to check out the music without waiting to download but the standard version of Quick Time does not allow you to save the file once it is downloaded.
Any suggestions on how to achieve this?
03-27-2006, 11:30 AM
You tell them to right click, save as, on the link.
Or they can click it and stream.
Even if you coded some complex setup checking their preferences, setting cookies, doing forms, storing the prefs in a database... whatever the heck you want, you'd STILL, to be able to act on those prefs, make a way to force them to download the file.
the point is... you can't do that, from what I'm hearing. Which, yeah, isn't too great, but it's what you gotta work with.
that's the easiest option but the website's in Flash and when you right click all you get is the flash options, no save target as. The only way I can think of the get around it is to have the link open up a pop up window with the html link in it, users can then right click to download the link.
This would require building a seperate html file for each song to downlaod, unless there was a way to have one html page for the pop up and then pass a variable from the flash link into it. My knowledge of HTML is pretty basic, any tips?
The easiest way to do it is to compress the file, as I've already mentioned. Almost all users have their browsers set up to download a compressed file, rather than opening it with a plugin. Note that this won't work for image files.
03-28-2006, 07:10 AM
It's funny now that I think about it; there are so many efforts and semi-workable ways to do the exact opposite.
You can force someone to stream, or come darn close, but you don't seem to be able to force a download. Interesting.
It's impossible to force a user to handle the data you supply in any given way. Once the user downloads the data, it's in their hands (and those of their system).
The system is what we depend upon when trying to get the user to download or stream something rather than the alternative. We just have to hope it adheres to the norms. However, there will always be systems that don't, and users who would rather take personal control. Therefore, this should never be relied upon.
03-28-2006, 02:59 PM
If it was possible to force the download of things the internet would not exsist, because computors would not be able to run. this because of people forcing the download of viruses. just thought id get you thinking on that
I think you missed the point of this.
Firstly, downloading malicious code is quite harmless. I have a few on my machine I've been studying, actually. Only if the code is run does it pose a threat (which is why I use qemu ;)). The issue here was not forcing a download, but forcing the browser to perform a specific action on the data after the download, such as opening it in a media player -- or, in this case, not opening it in a media player.
03-28-2006, 03:10 PM
ow oops, my mistake. Sorry about that but know in that case that is inpossible. I have never saw it done before and don't think i will for a long time :p
04-08-2006, 08:56 AM
This fellow seems to have found a solution that works with all browsers (but this is only if you are being hosted on a Windows Server and can make/request the change).
See [for explanation]:
See [for an example of this in action, simply click the link to download this movie]:http://www.pmcmovies.com/
04-08-2006, 12:41 PM
This fellow seems to have found a solution that works with all browsers (but this is only if you are being hosted on a Windows Server and can make/request the change).He hasn't, and it'll work with any server; only the instructions are for IIS.
The Content-Disposition header - which originates from MIME not HTTP, but is quite widely implemented by browsers, nevertheless - is well-known, but not foolproof. Most notably, older IE browsers fail to react to it properly, though they aren't the sole offenders.
The previous comments still stand.
04-11-2006, 02:11 AM
I was checking out some stuff at php.net and this was in one of the comments for readfile()
If you want to force a download:
$file = '/var/www/html/file-to-download.xyz';
header('Content-Description: File Transfer');
header('Content-Length: ' . filesize($filename));
header('Content-Disposition: attachment; filename=' . basename($file));
Might be helpful... hope it is...
04-11-2006, 04:32 AM
I was checking out some stuff at php.net [...]This should be obvious, but just because something is in the PHP documentation doesn't necessarily make it worthwhile. What you've posted is just more of the same unreliable code.
The problem - with IE, at least - is that the user agent is broken: it either tries to guess what type of content has been received, or ignores the application of the Content-Disposition header. With regard to the former, this sort of behaviour is a direct violation of RFC 2616 (HTTP/1.1 Specification) when a Content-Type header is present. In this situation, which almost always the case, the Content-Type header is authoritative.
In either case, no number of headers can cure the problem if the user agent is intent on doing stupid things. Just stick to what's sensible: send a Content-Type header with the value 'application/octet-stream' and a Content-Disposition header with the value 'attachment' (optionally followed by a suggested file name). It also seems that you should avoid using any form of content coding, such as gzip or deflate, for downloads.
Incidentally, if you go about creating a MIME type, as in the example:
header('Content-Type: application/force-download');specify an experimental sub-type. That is, the MIME type above should be application/x-force-download, however a client should treat that in exactly the same way as application/octet-stream.
04-11-2006, 07:04 AM
Hey, I just found the chunk of code. Seemed like they thought it worked, so I'm passing it on. :)
Aside from guessing from the language in the code, I have no clue what it does or how well it'll work in IE and such... just might be helpful.
but, yeah, from what you're saying... does sound like IE won't be helpful no matter what code you use. Well.... yeah. :p
good luck anyway.
04-11-2006, 06:39 PM
Hey, I just found the chunk of code.I know. I'm not trying to chastise you, or anything like that. :) I'm just trying to point out that when doing it the proper way doesn't work, it's because the browser is broken, or it doesn't understand the Content-Disposition header (the latter is fine, except in the case of IE). There's nothing you can do to fix that.
 IE has been written to understand the Content-Disposition header. Therefore when it doesn't, it's broken.
04-11-2006, 07:13 PM
Sorry... I was tired. That came out your. You're right, and the link I posted is probably wrong. Figured it might lead to something usefulu at least.
So... yeah... sounds like there's no good solution.
I had one more thought.
If you're so serious about this, then
1. Figure out another system that will force it to be downloaded... like using some freeware to make an .exe that includes and plays the music. This seems like a bit much for what you're talking about though.
OR 2. As has been said before, use a .zip. Easy, a bit annoying for the viewer, but whatever. It'll do basically the same thing as (1), but will be a heck of a lot easier for you.
#1 could actually be just an extension to #2. I don't know whether it's an extension to the format, or a cunning reworking of the resulting binary file, but it's possible to have a valid ZIP file that is also an executable that can be used to extract itself. Of course, it could not be an executable file at all, but interpreted somewhere along the line; Windows has some odd ideas as to what constitutes a .exe file. Anyway, I've also seen these files have an option of a file or program to open afterwards.
This is pure speculation, of course; I've no idea how this is achieved.
Oh, and Windows users might suspect a virus and refuse to open it, not knowing that it's also a valid ZIP file that they don't have to execute.
04-11-2006, 10:16 PM
I don't know whether it's an extension to the format, or a cunning reworking of the resulting binary file, but it's possible to have a valid ZIP file that is also an executable that can be used to extract itself.As far as I'm aware, self-extracting archives are simple decompressors wrapped around compressed data. They are most definitely executables, but as they're always prepared in the same way they can just assume that data will be present in a particular part of the file and, as a result, always mapped into the same region of memory relative to the base address for the executable code itself. In addition, because the format is so predictable, archivers like WinRAR know exactly where to look in executables to detect compressed data, and therefore they can offer to handle the data themselves.
I can't be certain without some analysis, though; the above is what I'd expect.
Of the ones I've seen, self-extracting archives in *n?x are quite literally shell scripts with a tarball tacked on the end. The end of the script is piped into gzip, then tar, using tail.
As far as I'm aware, self-extracting archives are simple decompressors wrapped around compressed data. They are most definitely executables, but as they're always prepared in the same way they can just assume that data will be present in a particular part of the file and, as a result, always mapped into the same region of memory relative to the base address for the executable code itself. In addition, because the format is so predictable, archivers like WinRAR know exactly where to look in executables to detect compressed data, and therefore they can offer to handle the data themselves.An extension to the format, effectively, then. :)
Of the ones I've seen, self-extracting archives in *n?x are quite literally shell scripts with a tarball tacked on the end. The end of the script is piped into gzip, then tar, using tail.Occasionally a binary executable is used rather than the shell script.
04-11-2006, 11:57 PM
Sure. That still requires using a zip of some sort. What I was thinking give a bit more control over how its presented, but, then again, why not just go with what you're saying or a plain zip.
And... self extracters are .exes, I from what I've seen. mike's right there.
Heck. Easy way: save your file with a new extension. Let them download. Tell them to change it to .mp3 or whatever we're talking about; I forget.
But... probably a bit more user friendly to use zips anyway.
And... self extracters are .exes, I from what I've seen. mike's right there.That was never in doubt :) However, Windows groups a lot of things under the extension ".exe".
But... probably a bit more user friendly to use zips anyway.Yup. :p
04-12-2006, 03:53 AM
Can't JS determine the browser then not let IE people do anything?
04-12-2006, 10:47 AM
Can't JS determine the browser then not let IE people do anything?Client-side scripting cannot fix this. Moreover, browser detection is flawed both as a concept, and in practice. Don't do it.
04-13-2006, 08:40 AM
Eh, php could, then only let people using non-IE browsers view it.
Ha, problem solved.
and like 70% of your viewers blocked! Woot! :p
Haha... just curious about the idea... but it's clear we've determined it's just not gonna happen, and to just go with .zip. Yep.
07-18-2006, 02:49 AM
I was looking for the same solution on my website and I've got it working on mine now:
I found a nice little article here:
And modded it for my given application - tested...SWEET...werks gud.
Powered by vBulletin® Version 4.2.1 Copyright © 2014 vBulletin Solutions, Inc. All rights reserved.