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.
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.
I've worked on a lot of cross browser bugs since IE5, never seen one created by any header or created by omitting http headers. Honestly your comment is just nonsense.
IE9 is the only browser among safari/chrome/firefox/ie that I can't get to render html5 audio tags, or respect document.createElement('audio').canPlayType tests. Ridiculous.
Although it's not guilty of this particular idiocy, IE does like to override MIME types by content- or extension-based guesses. So it would, sadly, not be that surprising.
<input type='file'> is unbelievable for its inability to be styled. IE is even more bizarre in that it displays the full path of the file chosen in a text field with a blinking cursor like you can type when active but ignores keyboard entry - except the backspace or delete keys that removes the file if there is one selected. IE11 changed file selection from double-click on mystery text field to single click on mystery text field. Browse always worked however.
I avoid IE too, but about 52% (and shrinking) visitors to sites I work with still do use IE so we still have to deal with it.
This is the first article I've read about this problem (thanks, HN.) Here's a quick summary of what I think I need to do about it: (corrections appreciated)
1) For any situations where you allow users to upload files which may be sent back to the browser as images, run some kind of check to ensure it's a valid image, e.g. ImageMagick "convert"
2) ensure you return content-type headers with the correct image type.
It's kind of ironic that this article praises IE, yet the article itself doesn't display properly in IE. The main article content is covered by the current projects. Works fine in Chrome though.
I did server side browser sniffing to give IE the version it understood (IIRC it couldn't handle well-formed XHTML served with the proper mime tag, not sure, it's been a while :D) while everything else got proper fully compliant XHTML. I'm pretty sure I used a code snippet from Anne van Kesteren who is also posting here ;)
OK, the spec is flawed. Other browser makers have solved that problem quite neatly by not implementing it.
It's also my opinion that while the implementation is strictly speaking correct, IE's default settings are too conservative and it is not at all an easy option for the user to change.
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.
reply