Summary

Web sites that use the "application/x-msexcel" or "application/vnd.ms-excel" MIME type to open web page content inside of Microsoft Excel may encounter the following warning prompt when the file attempts to open in Excel 2007:

"The file you are trying to open, '[filename]', is in a different format than specified by the file extension. Verify that the file is not corrupted and is from a trusted source before opening the file. Do you want to open the file now?"  (Yes | No | Help)

If the user clicks Yes, the file will open as expected.  If the user clicks No, the file may open anyway, or may prompt a second time, and then not open if the user selects No again.  

Cause

The alert is a new security feature in Excel 2007 called Extension Hardening, which ensures that the file content being opened matches the extension type specified in the shell command that is attempting to open the file. Because the MIME types listed above are associated with the .XLS extension, the file must be in XLS (BIFF8) file format to open without this warning prompt.  If the file type is a different format (such as HTML, XML, CSV, etc.) the prompt is expected since the file content is different that the extension or MIME type. The alert is first seen when opening the file from a URL site directly.  If you cancel the alert, the open will fail, but then IE will attempt to download the file and open again using a different shell command. Depending on what the file contents is and what extension IE gives the file it downloads, you may see the second open attempt succeed, or you may see the prompt again but with a different filename in the alert dialog.

The alert prompt is "by design", but the interaction of the cancel action and IE's attempt to open the file again is a known problem under investigation for a future fix. 

More Information

Microsoft Excel 2007 provides new MIME types for the new Open XML file types, which you should instead when returning those content types.  For a full list of the document types and the correct MIME type header to use, see this posting:

Office 2007 File Format MIME Types for HTTP Content Streaming

Web sites should return the MIME type for the matching extension type of the content they return. 

If the content is not a native Excel file format, but is instead a text based format (such as CSV, TXT, XML), then the web site can add the following HTTP header to their GET response to tell IE to use an alternate name, and in the name you can set the extension to the right content type:

Response.AddHeader "Content-Disposition", "Attachment;Filename=MyBook.csv"

The current design does not allow you to open HTML content from a web site in Excel unless the extension of the URL is .HTM/.HTML/.MHT/.MHTML. So ASP pages that return HTML and set the MIME type to something like XLS to try to force the HTML to open in Excel instead of the web browser (as expected) will always get the security alert since the content does not match the MIME type.  If you use an HTML MIME type, then the web browser will open the content instead of Excel. So there is no good workaround for this case because of the lack of a special MIME type for HTML/MHTML that is Excel specific.  You can add your own MIME type if you control both the web server and the client desktops that need access to it, but otherwise the best option is to use a different file format or alert your users of the warning and tell them to select Yes to the dialog.

Client Configuration of Extension Hardening

Client desktops can change the default behavior of the security check using a registry key.  The following registry key can be set to alter the behavior of the Excel 2007 client in the following ways:

Key: HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Excel\Security
Value: (DWORD)"ExtensionHardening" = [0 = Disable check; 1 = Enable check and prompt; 2 = Enable check, no prompt deny open]
Default setting if value not present is 1 (enable and prompt).

The client can configure the site to disable the check by setting ExtensionHardening = 0.  This will stop the prompt from appearing, but it will also disable any future checks for the file content validity.  This does not (in itself) lower your security.  The check is part of a defense-in-depth strategy to prevent malicious users from crafting files of a different type than its extension (or MIME type), which could then be used to trick users into opening a file of a type they did not expect.  This warning is designed to let the user know of this potential threat and given them an option of canceling the open if they wish.

The problem with the file still opening if the user selects No to the warning dialog occurs under a unique situation where the file is actually in the correct file format for its MIME type, but the MIME type cannot be determined at the time of the open from the moniker being used nor from the URL itself. For example, consider an ASP page that returns an BIFF8 XLS file from a database. If it uses the correct MIME type for XLS file type, the user may still get prompted with the alert depending on the open method IE uses to try to open the document. This is a false positive case which occurs because Excel cannot get the MIME type at the time of the open, and the extension in the URL is ASP (or ASPX) and not XLS. So Excel decided it should prompt the user. If the user says No to this open, IE will download the file and save it in the cache.  When it does this, it adds the XLS extension to the cache file. IE then opens the local copy. Because the extension on the local copy matches the correct file content type, the prompt is not seen again and the file opens. From the user perspective it appears the No button failed to cancel the open. That is not entirely true, because it was canceled. However, IE chose to open the file in a different way, and that attempt can work.  If the file was not in the right MIME type, the user may see a second prompt, and therefore has to press No again to cancel the second open attempt.  This issue only occurs when using IE for your web browser.  This issue is still being investigated, but a fix is not likely until Office 14 given the nature of the complexity of the code, and the fact that Excel does not want to lower the security measure to workaround IE open behaviors without a full understanding of the consequences for other browser users.