SharePoint ignores MIMEtypes mapping unless on web server level

Earlier I reported that our business users request user-intuitive handling of non-Microsoft and non-standard file-formats that are administrated within document libraries. Enabling such in SharePoint on premise consists of 2 steps (See ‘SharePoint: Browser File Handling Deep Dive’ for an authoritative reference):

1. Add in IIS Manager a MIMEtype mapping for the involved file-extension(s)
2. Add the MIMEtype(s) to the AllowedInlineDownloadedMimeTypes configuration of the SharePoint webapplication(s)

These server-level configuration steps are not possible in Office 365 / SharePoint Online. I ensured that we can deliver our business users sustainable custom filetype handling on migrating to cloud deployment, via the utilization of Office 365 FileHandler Add-Ins concept.

Wrt MIMEtype mappings, IIS allows multiple levels on which you can configure these:

• Web server
• Site
• Application
• Physical and virtual directories
• File (URL)

Note that not all these levels are applicable to SharePoint as virtual webserver.

The web server level is most easy to execute, but drawback is that it requires an IISReset to become active. And that means a temporary down of any SharePoint webapplication hosted on the WFE. Therefore I instructed our operations to add the MIMEtype mappings on the Site level. To be disappointed afterwards: on download of the files from SharePoint, the content-type was still ‘application/octet-stream’ aka the “unknown type”, instead of the configured MIMEtype e.g. ‘application/vnd.spotfire.dxp’. Only when we add the MIMEtype to web server level, SharePoint returns in the file download response the configured MIMEtype.

I conducted an internet search on whether this is intentional, or at least known SharePoint / MIMEtype (mis)behavior. Only found some discussion posts ([1], [2]) inquiring about the effect we noticed (on SharePoint 2010 and SharePoint 2013 Server farms).

Future-proof handling of custom filetypes in SharePoint document libraries

Build Office 365 FileHandler to return external filetypes with application specific MIME-type(s)

Business in our company works with programs that store data in non-Microsoft and non-standards file-formats, e.g. Mathlab files, MindManager, Spotfire reports, ... Their aim is to store these file-formats also on SharePoint. Two SharePoint issues are an obstacle here.

SharePoint blocks file-extensions for upload

SharePoint blocks a large number of file-extensions for document library upload: Types of files that cannot be added to a list or library. However, in SharePoint 2016 this list is severely reduced to only few .Net programming files left, and in SharePoint Online the file-extension blocking is even completely gone. We’re not yet on SharePoint 2016 nor Online, but our roadmap is heading towards this. Therefore it is viable to relax the blocking to the minimal list of SharePoint 2016.

No recognition of application-specific MIME-type

SharePoint storage is agnostic for file-contents and extension. It can store whatever binary content in the content database as file. However, upon retrieving + opening a file from SharePoint document library, SharePoint has no recollection what to do with the unknown filetypes, and does a best guess. This results that e.g. a Tibco Spotfire report file with extension .dxp, is returned by SharePoint as a .zip file. And next cannot seamless be opened in the Spotfire Player. Same for Mathlab files, MindManager / MindMab, … In SharePoint on-prem you can overload this behavior via configuration of custom MIME-types. However, this is a WebApplication plus IIS setting, and thus clearly not available for usage in SharePoint Online tenant context. This withholds us now from utilizing the on-prem approach, as otherwise we would introduce business disruption upon going to the cloud.

Yet, recently I came across the concept of Office 365 FileHandlers and this promised to be a cloud-ready manner to achieve the same effect. I conducted a proof-of-concept with positive outcome: via a custom build Office 365 FileHandler Add-In that connects to the SharePoint Online site via the Office 365 Graph API, is deployed in Azure and registered in Azure AD, it is possible to open and return non-standard filetypes with custom MIME-types. The FileHandler Add-In concept allows to register multiple handlers, e.g. per specific filetype; and also to have a single FileHandler Add-In that can handle multiple filetypes. For my PoC, I needed to verify that custom MIME-types can be returned in the HTTP-response, and I wanted to validate this for multiple file-types. I therefore restrained to one, and determine in the FileHandler on basis if the extension-part of the filetype, the MIME-type to include in the response. Only disadvantage of this is that the FileHandler administration only allows 1 file-icon association, thus all file-types for which the FileHandler is registrated are displayed in Office 365 document libraries with the same icon.

Office 365 FileHandler applied to SharePoint Online site:

Click to select/download Spotfire file with .dxp extension, result:

and open on client in Spotfire Player application:

Code snippet FileHandler MVC open action to return file-content with application-specific content-type:

ToDo, figure out WOPI protocol against SharePoint Online

SharePoint Online acts as a Web Application Open Platform Interface (WOPI) host, and interacts via the WOPI protocol. A result is that in Office 365 FileHandler activation-parameters the file is identified by WOPI 'FileId' parameter. In my 'generic' FileHandler I want to return the application-specific MIME-type per configured file-extension (remember: I have the single FileHandler Add-In associated with multiple file-extensions), and therefore need the filename with the extension. The WOPI protocol supports this via 'CheckFileInfo' action. So far, I did not manage to get this working, still run into errors on illegal REST requests wrt WOPI protocol. To be continued...