AFAIK in MIME sniffing IE guessed file type based on its content [1], not URL. And given that IE is rarely used nowadays not sure if it still relevant.
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.
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.
Chrome also added special handling to work around poor browser sniffing in Hotmail, which is ironic because Opera had to do the same for Google Docs. Opera claims that most of what they have to deal with is actually improper browser sniffing on sites that didn't work in a previous version of Opera but work fine now. Looking at Microsoft's list of sites, it seems to be a similar story, many sites have IE-specific code that isn't necessary in IE9.
if (/MSIE (\d+\.\d+);/.test(navigator.userAgent)) {
alert(
"Unfortunately, this tool does not currently work in Internet Explorer. " +
"Please try another browser such as Firefox, Chrome, or Safari.");
return;
}
That's not very nice. Surely this can be made to work for at least IE9 :)
If you spoof your user agent, or use IE11, you don't get redirected to the "crying" page (the page uses 301 redirection BTW).
Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv:11.0) like Gecko
Also worth noting, an excerpt from the IE blog[1]:
Obviously, maintaining Compatibility View Lists requires a significant investment
on the part of the IE team—resources which could be used to implement more
new standards, performance improvements, etc. Please please please: use
feature detection rather than User-Agent sniffing.
If the IE team doesn't want people to use UA sniffing, they should teach by example.
IE version 6: Mozilla/4.0 (compatible; MSIE 6.0b; Windows NT 5.1)
IE version 10: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; Trident/6.0)
IE versi--wait, what (?!): Mozilla/1.22 (compatible; MSIE 10.0; Windows 3.1)
That last one made me wonder if someone was trolling an auto-collection system or if a zero somehow got added by a Network™. Offtopic but had to add it.
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 ;)
Subset? Isn't it more like a super set? IE6 (and above) has no files array that can be read with a FileReader and it only supports the types "Text" and "URL", no support for proper mime types.
I've tested the protocol-relative URL in every version of IE that was available on Browsershots about a year ago (which went back even further than IE6, IIRC). None of them had trouble with it.
IE compatibility mode is broken. It has two "modes", one of which changes the user agent version and one that doesn't (but still changes the functionality of the browser). Guess where the sniffer scripts get the version from.
The only way to make it work reliably is to look at the window.documentMode property which requires changing your code, thus defeating the point of the compatibility mode in the first place.
Someone please correct me if I'm wrong, but at least in my testing, IE blocks the file:// request for any non-intranet site. So it won't work with just any webpage.
[1]: https://docs.microsoft.com/en-us/previous-versions/windows/i...
Update: tested this link in FireFox 92 - it still performs sniffing in 2021: http://www.debugtheweb.com/test/mime/script.asp (based on the content, not extension)
reply