Oh how I wish that were true.

It's what's intended, but it's not what's true. Usually this bites on video, but it even bites on, say, SVG:

http://stackoverflow.com/questions/10261460/internet-explore...

Ostensibly, this is to protect users. Quoting TechNet:

When files are served to the client, Internet Explorer uses the following pieces of information to decide how to handle the file:

1. File name extension, the corresponding ProgID and CLSID for the registered handler of that file name extension.

2. Content-Type from the HTTP header (MIME type), the corresponding ProgID, and CLSID for the registered handler of that Content or MIME type.

3. Content-Disposition from the HTTP header.

4. Results of the MIME sniff.

-- http://technet.microsoft.com/en-us/library/cc787872(v=ws.10)...

If IE chooses to use file extension over MIME type, then it is broken and should be ignored.

Yes, I'm aware that this is probably a workaround for broken web servers, or brain-dead server admins. This workaround should never have been deployed, as it breaks interactions with non-broken web servers.

It's not just IE that plays loose like this. Chrome will ignore even the Content-Type header if it can see the content is an audio or video file. For example, upload a .wav to puush and open it in FF and Chrome. FF will show a dump of the bytes interpreted as text because the server sent it with Content-Type: text/plain. Chrome will show an <audio> element.

You can't call either browser broken here. One is doing what the spec says is correct. The other is doing what the user says is correct.