<p>Handling files in the VPP folders usually works fine out of the box. While troubleshooting a MIME type problem, I discovered something I thought I'd share as it was a frustrating debugging session and the solution is quite...interesting.</p>
The very problem I had was serving an ODT-file from VPP folders. It always returned the file with MIME-type
application/octet-stream - which just is not correct. Most browsers handle this fine, and see the ".odt" in the file name, and open the file in Office/OpenOffice. However - drumroll - Internet Explorer doesn't. It wants to open the file as a ZIP-file. To be fair, this isn't wrong, since the file itself really is just a ZIP-file in disguise, but it's not very practical.
If I put the file in the application folders, however, IIS' MIME mappings came into action and served the file correctly as
application/vnd.oasis.opendocument.text. So obviously, EPiServer's StaticFileHandler does something with the response headers that IIS' file handler does not.
After some digging, I found that the class
EPiServer.Web.MimeMapping has a method
AddMimeMapping(string extension, string mimeType). So my final solution was to add the following to
Application_Start in Global.asax.cs:
...and of course, creating functionality for retrieving MIME-types from IIS or some other source shouldn't be a problem, but this is the essence of the solution.
I'm not sure I like this however. I can't see any reason why EPiServer doesn't use IIS' own built-in MIME mappings like the web application itself does. I guess it might be legacy code, but still - as far as I know, support for a customizable MIME mapping table has existed in all web servers since forever.