If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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.

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[1]). There's nothing you can do to fix that.

Mike

[1] IE has been written to understand the Content-Disposition header. Therefore when it doesn't, it's broken.

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.

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.

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.