|Bypass Quicktime to Direct Download|
Some sites can force users with Quicktime to download instead of playing
| 7:51 pm on Oct 14, 2009 (gmt 0)|
On my website I have linked to a locally stored MP3 file. Normally when a user clicks the file they get a box asking them to open or save it. However, people who have quicktime installed (thanks Apple) instead go to a new window where the track plays.
I personally know how to disassociate quicktime from my browser, however most of my users do not. I am looking for a way to force a download regardless of whether or not the person has QT installed.
I know this is possible because sites do it. In searching through the code I cant figure out how though.
< no example links, please - see Forum Charter [webmasterworld.com] >- this is an example, even I have QT enabled it downloads the file.
[edited by: tedster at 8:35 pm (utc) on Oct. 14, 2009]
| 8:28 pm on Oct 14, 2009 (gmt 0)|
I would wonder if the guys in the PHP forum could provide you/us with a script that does exactly what you want, and explain how to edit for specific file types. That would be my first choice.
Just need to find somebody to give up a script and explanation. You could probably search for a PHP solution easily enough, but no reason this can't be answered in-house.
The no-effort, no-learning way out is to drop your .mp3 in .zip and link to that. LOL
| 9:25 pm on Oct 14, 2009 (gmt 0)|
You're looking for the "Content-Disposition" header (see RFC 2183 [ietf.org], or section 19.5.1 of RFC 2616 [w3.org]).
In short, you'll want to add something like
to the HTTP headers you output for that file.
|Content-Disposition: attachment; filename="whatever.mp3" |
| 11:12 pm on Oct 14, 2009 (gmt 0)|
Interesting so just adding that within the Head tags will force the browser to download? I just need to specify the name of the mp3 on the page?
Thank you for helping.
| 1:18 am on Oct 15, 2009 (gmt 0)|
|so just adding that within the Head tags |
No, this is not a page <head>, it's a http header, the data sent to the browser BEFORE the content delivery. You can see http headers by loading the FireFox extension "Live HTTP Headers" and opening any page.
Content-disposition helps, but it's not always enough. Browsers sometimes "sniff" a file type. If it can detect a particular type and has a "helper application" available it will still try to display it.
Usually this is best done by printing out a munged content-type header, which forces the browser to prompt download.
PHP, perl, ASP, doesn't matter:
print "content-type: bad/type\n";
print "Content-Length: $size\n";
print "Content-Disposition: attachment; filename=$filename\n\n";
then open and print out the file to the browser.
Those are the basics, PHP seems to need a bit more, Google for "force download PHP" if this is your language of choice.
| 2:09 am on Oct 15, 2009 (gmt 0)|
"application/octet-stream" would be a better* choice for the Content-Type header than "bad/type". Especially considering
from aforementioned RFC 2616 section 19.5.1.
|If this header is used in a response with the application/octet-stream content-type, the implied suggestion is that the user agent should not display the response, but directly enter a `save response as...' dialog. |
* "better" here meaning "more in line with the RFC" rather than "functionally superior".
| 6:11 pm on Oct 15, 2009 (gmt 0)|
Yes but . . . it's not always an application. I've had some goes at this when trying to force a download, and using application/octet-stream has prompted an "open with/save file" prompt instead of the intended save dialogue.
"Bad/type" is just what I use to "munge" the content-type header. It could be anything, as long as the browser doesn't recognize the content-type. "Content-type:IE-is-a-pain\n"; :-)
With PHP though, there are specific headers required and it does use octet-stream, and appears to work. So I guess it depends on the technology.
| 11:18 pm on Oct 15, 2009 (gmt 0)|
Assuming that's a play on the existence of more appropriate top-level MIME-types for DJFlite's case: yes, "audio/mpeg" would be more accurate. Otherwise: "application", in MIME-speak, doesn't mean "this thingy is an application" so much as "here's some binary data" (see RFC 2046 sections 3 and 4.5).
Regardless, if you're silly enough try avoiding the very useful "Open with" part of certain browsers' downloading UI, I guess you gotta go with whatever works for you. :P