MIME Type Detection in Windows Internet Explorer

In Microsoft Internet Explorer 4.0 and later, MIME type determination occurs in URL monikers through the FindMimeFromData method. Determining the MIME type allows URL monikers and other components to find and launch the correct object server or application to handle the associated content. This section provides a brief summary of the logic used in determining the MIME type from these sources, and also discusses some of the issues involved.

This topic contains the following sections:

• MIME type Detection Algorithm
• Uploaded MIME Types
• Known MIME Types
• Registry Locations
• MIME Sniffing Feature Control
• MIME Handling changes

MIME type Detection Algorithm

The purpose of MIME type detection, or data sniffing, is to determine the MIME type (also known as content type or media type) of downloaded content using information from the following four sources:

• The server-supplied MIME type, if available
• An examination of the actual contents associated with a downloaded URL
• The file name associated with the downloaded content (assumed to be derived from the associated URL)
• Registry settings (file name extension/MIME type associations or registered applications) in effect during the download

FindMimeFromData contains hard-coded tests for (currently 26) separate MIME types (see Known MIME Types). This means that if a given buffer contains data in the format of one of these MIME types, a test exists in FindMimeFromData that is designed (by scanning through the buffer contents) to recognize the corresponding MIME type. A MIME type is known if it is one of these N MIME types. A MIME type is ambiguous if it is "text/plain," "application/octet-stream," an empty string, or null (that is, the server failed to provide it). A MIME type that is neither known nor ambiguous is termed unknown. The MIME types "text/plain" and "application/octet-stream" are termed ambiguous because they generally do not provide clear indications of which application or CLSID should be associated as the content handler. A MIME type inferred from any one of the four possible sources can be categorized into one of these three classifications.

FindMimeFromData typically receives three parameters when invoked—the cache file name (assumed to be derived from the associated URL), a pointer to a buffer containing up to the first 256 bytes of the content, and a "suggested" MIME type that typically corresponds to the server-provided MIME type (through the content-type header). Determining the MIME type proceeds as follows:

1. If the "suggested" (server-provided) MIME type is unknown (not known and not ambiguous), FindMimeFromData immediately returns this MIME type as the final determination. The reason for this is that new MIME types are continually emerging, and these MIME types might have formats that are difficult to distinguish from the set of hard-coded MIME types for which tests exist. A good example of this is SGML, which can easily be classified incorrectly as HTML because it contains many of the same tags. Rather than weakening the hard-coded tests or risking the incorrect classification of new and as-yet-unknown MIME types for hard-coded known ones, priority is given to the server-supplied MIME type if it is unknown, because these MIME types are both specific and likely uncommon, and there are no hard-coded tests that can positively identify them.
2. If the server-provided MIME type is either known or ambiguous, the buffer is scanned in an attempt to verify or obtain a MIME type from the actual content. If a positive match is found (one of the hard-coded tests succeeded), this MIME type is immediately returned as the final determination, overriding the server-provided MIME type (this type of behavior is necessary to identify a .gif file being sent as text/html). During scanning, it is determined if the buffer is predominantly text or binary. Note  In Microsoft Internet Explorer 6 for Windows XP Service Pack 2 (SP2), the MIME type "text/plain" is not ambiguous, and is never rendered as HTML in the restricted zone, even if the content suggests that this is the correct format.  
3. If no positive match is obtained during the data scan, and if the server-provided MIME type is known, an attempt is made to determine if the format (text or binary) of the known MIME type conflicts with the format (text or binary) that was determined from scanning the buffer. If no conflict exists (the data scan indicates primarily text and the server-provided MIME type has a text format, or the data scan indicates binary and the server-provided MIME type is a binary format), the server-provided MIME type is returned. The reasoning behind this is that new formats of MIME types might be added over time (image/tif is one example) and the hard-coded tests might not recognize these new formats (a different pattern match might be required). With the assumption that the basic format of MIME types will not change over time from primarily text to binary or vice versa, it will suffice that the formats of the server-provided MIME type and the format found from scanning the data do not disagree. If this is the case, the server-provided MIME type is returned. The format types for known MIME types are stored in a media information structure in URL monikers.
4. If no positive match is obtained during the data scan, and the server-provided MIME type is ambiguous or the server-provided MIME type is known, and the data format agreement test in the previous step failed, an attempt is made to parse a file name extension from the file name passed in. If this is successful, an attempt is made to find the MIME type associated with the file name extension in the registry. This will be returned as the final determination if the MIME type associated with the file name extension is unknown. The reason for this added requirement is as follows: If the file name extension yields an ambiguous MIME type, this adds no information to what was already obtained through scanning the data. If the file name extension yields a known MIME type, this MIME type should have been found during scanning. Because it was not found, it is suspect, and is rejected. An example of this is an arbitrary plain-text file being returned through an ISAPI DLL, with the server returning 'text/plain' as the MIME type. Because the server-provided MIME type is ambiguous, a scan of the data is conducted that only confirms that the data is plain text. Subsequently, the file name is parsed for an extension. In this case, because the contents were downloaded using an ISAPI DLL, the URL and hence the cache file name will have a .dll file name extension that has the MIME type "application/x-msdownload" associated in the registry. This MIME type was already scanned for (application/x-msdownload is a known MIME type), was not found, and is therefore the wrong determination (this results in a file download as opposed to the desired behavior, which is to display the text in-pane).
5. If all the preceding steps have failed to yield an unambiguous MIME type, a last check is made to see if any application is associated in the registry with the file name extension parsed from the file name, if one exists. If an associated application is found, the final determination is automatically set to "application/octet-stream." This default value ensures that the registered application will be launched by the shell with the downloaded data, rather than displaying the data in-pane. As an example, this is necessary when downloading, among others, .bat and .cmd files, which are plain text files, are frequently identified by the server as "text/plain," and have no associated MIME type in the registry. Without the final check for an associated application, these would be displayed in-pane, whereas the desired behavior is to launch the command interpreter. This is ensured by checking for an associated application, and defaulting to the final determined MIME type of "application/octet-stream." Other types of files, such as .reg files, behave similarly.
6. Finally, if no file name extension is found, or one is found with no associated MIME type or registered application, the MIME type "text/plain" is returned if the data scan indicated predominantly text, or "application/octet-stream" if the data scan indicated binary, because this is the furthest correct determination that could be made.

Uploaded MIME Types

When uploading files from the client to the Web server, Windows Internet Explorer uses FindMimeFromData to determine a MIME type. Where possible, FindMimeFromData returns hard-coded values from the list of Known MIME Types rather than relying on the MIME type value associated with the file name extension in the system registry. In some cases, the detected MIME type can differ from the generally accepted value for backward compatibility, as shown in the following table:

Known MIME Types

FindMimeFromData tests for the following MIME types:

Registry Locations

Location used by FindMimeFromData to find MIME type and progID from file name extension:

HKEY_CLASSES_ROOT\.***

Location used by FindMimeFromData to find application from progID:

HKEY_CLASSES_ROOT\<ProgId>\shell\open\command

Location used by URL monikers to find CLSIDs from MIME types:

HKEY_CLASSES_ROOT\MIME\Database\Content Type

MIME Sniffing Feature Control

In Windows XP SP2, a feature control was added to enable and disable MIME sniffing. For more information on feature controls, see Introduction to Feature Controls.

MIME Handling changes

Windows Internet Explorer in Windows XP SP2 handles MIME types differently than previous versions. For more information, see Handling MIME Types in Internet Explorer.