As a consultant, I get to help companies with various projects. A recent project included migrating a SharePoint 2010 site running on Beta 2 software (10.0.4536.1000) to RTM software (10.0.4762.1000). This presented many challenges as the original server build and configuration steps were long gone. My job was to document to necessary steps to migrate the content from the production site to a new site on RTM software. That story aside, a publishing site master page on the site injected an IFrame with a source of a .htm file that was stored within a document library. On the production site, everything worked fine. However, on the site I created from scratch, I continually got either a “Information Bar” warning or a download file dialog (based on my browser (IE 8.0) settings):
After Binging and Googleing with no easy answers , and based on the advice of a colleague, I pulled out Fiddler, which I should have done at the start. After finding the IFrame in the page and the subsequent browser get request, I saw the responsefor the file come back. At first glace, the response seemed fine. However, comparing it with the production site, the recreated site response headers had extra “stuff” in them. Here are the two response headers, the current production site first and the recreated site second in my favorite comparison software WinMerge:
Besides the date, time and various GUIDS, the only differences are the extra headers:
- X-Content-Type-Options: nosniff
- Content-Disposition: attachment; filename=filename.htm
- X-Download-Options: noopen
Wikipedia-ing these gives a little detail to the first two of their purpose and the final one being defined on an IE 8 security blog:
||The only defined value, “nosniff”, prevents Internet Explorer from MIME-sniffing a response away from the declared content-type
||An opportunity to raise a “File Download” dialogue box for a known MIME type
Content-Disposition: attachment; filename=fname.ext
||When the new X-Download-Options header is present with the value noopen, the user is prevented from opening a file download directly; instead, they must first save the file locally. When the locally saved file is later opened, it no longer executes in the security context of your site, helping to prevent script injection
The fact that the headers from the server are different even with the same browser shows that the server has some setting that is sending this “additional” headers.
Google-ing these headers produces some hits and the most documented one is:
It turns out it is it is a setting on the Web Application from within Central Administration:
However, it does not list what file types generate this behavior, instead only listing “certain types of files”.
Now that I know the area of what is producing this behavior, lots of sites have also documented the solution to my problem but I could not find them when I needed them
Still to be determined is why “.htm” is blocked even though it is not in the blocked file extensions in Central Administration. Any takers?
The blocked file types extension in SharePoint Central Administration/Security/BlockedFileTypes does not list .htm as blocked.
Powershell confirmed it as well:
$wa = [Microsoft.SharePoint.Administration.Spwebapplication]::Lookup($URL)