IE content-type logic

IE content-type logic

IE content-type logic

This being my first post on the IE blog, I should introduce myself quickly. My name is Vishu Gupta; I am a developer on the IE team.

There have been several posts in the recent past asking for more information on how does Internet Explorer sniff the content-type of a downloaded file. The whole thing looks totally inconsistent or should I say...non-compliant! Before reaching any conclusions here, let’s dig just a little bit deeper.

During XPSP2, we gave a real hard look at the IE's content-type handling code path and how to make it more secure and reasonable. The whole idea of the mime-sniffing logic was to make it easier for an average Joe to put up a personal website without worrying about mimetype details even when web servers and ISPs have random default configurations. IE does mime-sniffing only if either the server doesn't specify a content-type or if the server claims that the file is something that IE knows about. For example, if there is a new mimetype abc/xyz and the server reports that to IE, IE will consider the mimetype of the file to be abc/xyz only. In addition to the content-type sniffing, IE also does clsid sniffing, which actually decides which component handles the file within IE. The clsid can be either sniffed from the document itself or it can be obtained from the mimetype (decided previously with or without sniffing) or can be obtained from the extension. For example, if the mimetype abc/xyz doesn't have a clsid corresponding to itself in the registry, IE will try to obtain the clsid from the extension or from the document itself, and use that to host the file. If it cannot find the clsid, the file will be Shell Executed and shell will use the extension to determine the application to handle the file.

Now comes:
The question: "Do we really need to sniff a file if the server says it is text/plain?"
Short answer: No.
Long answer: Probably, we do.

During XPSP2 betas, we had the mimesniffing mitigation enabled in all zones by default. We tested the waters with applying the "server knows best, so treat the server-suggested mimetype as authoritative" concept for text/plain mimetype. This led to an outcry on the newsgroups about different file types being rendered as text on XPSP2, and we had to disable the mitigation in the internet zone. One can only imagine the app-compat backlash if we stopped sniffing for all reported mimetypes. Yes, instead of handling that by sniffing in the browser, we could go about asking everybody to fix their servers but not everyone can do that easily. In addition to this, several apps depend on IE to launch them after sniffing the correct clsid from their compound file (OLE structured storage). Its one thing to ask new apps to do the right thing, but a whole different ball-game if you want to switch the entire installed base.

Mimesniffing doesn't mean that there is no way for a server to control how a file is handled. header enables a server to do precisely that. With this however, IE makes sure that the user gets prompted with the file type information (based on the extension specified by the server here) before the file is opened/saved.

-Vishu

posted on Tuesday, February 01, 2005 7:22 AM