So when I (and others?) click the <file_name>.mp3 target to hear the attachments that are uploaded, the default action is to stream them through the browser. And worse, the stream duration seems to be inconsistent. Sometimes it would play three seconds. The next pass would be the first second. Etc.

in the .htaccess file (although, that would give you a performance loss compared to the httpd.conf).

Rather than treating file extensions of .mp3 as audio files (which are streaming through the browser through Quicktime and such), the .mp3 files will be considered binary files (hence application/octet-stream). This would mark the file as requiring an external application to open the file (local media player).

An example would be downloading a .xls file and being prompted to download the file to open in Excel at a later time.

I feel like this would save people time with the "Right Click > Save Target As" along with helping those who are not very familiar with computers. Especially if the fix is potentially a simple one, such as this.

If you're interested, I can provide a link to my personal web hosting where I added the AddType as listed above to my .htaccess file in order to test this before suggesting it.

Thanks.

--While on the subject, adding

ServerSignature Off

should get rid of some information regarding the server's configuration which is visible from the default 404 (File Not Found) page. This doesn't really provide security because there are other tools to detect and best guess a server's signature, but that's one more layer of defense in favor of RD. (Off-topic, I know.)

Or, you could use google chrome, which streams the whole thing (for some reason)

or just right click and download.

It does not make sense to force users to migrate from one browser to another unless there is a huge security risk or stagnant development of the application (ex. Internet Explorer 6). On my own hosting, streaming mp3 files works fine without the issues that I have with RD. There just seems to be an issue with the setup RD is using.

Consequently, I am suggesting a possible solution that has a low initial cost for the RD entity, in an effort to alleviate any problems that the general community may encounter. Streaming files multiple times rather than downloading the actual file and saving it to local disk would also save RD potential bandwidth which helps with their hosting costs.

Additionally, I already addressed your second statement in my original topic.

Quote

I feel like this would save people time with the "Right Click > Save Target As" along with helping those who are not very familiar with computers. Especially if the fix is potentially a simple one, such as this.

It's like you were reading my mind! I was going to tackle the download problem in the next few weeks but your post made me act sooner. The application/octet-stream doesn't work in our server's htaccess file but it does work when I re-defined the file types in the forum's backend. I'm still trying to figure out why our server began only streaming the first seconds of the file, but until then this looks like a pretty good solution.