I you are working on any application that needs to serve files on it’s own, for example for encrypted storage or a rich ACL that needs to be enforced, you will need to provide the most correct Content-Type possible or MIME type from a given file extension to the response in order to achieve the best user experience.
For example, if you serve a PDF and use a generic MIME like application/octet-stream, the user may not see a PDF reader to open it, depending on the browser and platform.
Then, in .NET there are 4 alternatives to do this, with their pros and their cons:
- Use the Windows registry - This may be a good solution for desktop applications but depends on the software installed on the machine and typically web servers don’t have Acrobat or Office.
- Use urlmon.dll’s FindMimeFromData - I don’t know exactly the effectiveness of this method, but it’s used internally by Windows. It should give good and reliable information but you have to read the file and give the method up to 256 bytes of the file header.
- Use IIS information - Maybe the most obscure mechanism, based on Directory Services and COM stuff. It’s based on the same mechanism IIS uses, so it should be quite reliable, but complex and may not be the fastest.
- Use your own dictionary - Maybe not the most elegant but even .NET uses this internally (inspect
System.Web.MimeMappingwith ILSpy if you are curious). You get a bunch of types from somewhere and add them to a dictionary with the associated extension. Easy.
So, the options are clear. Finally in my case, I used a simple dictionary to ensure compatibility between platforms and homogeneity. Using other mechanisms could lead to strange errors on some platforms that I wanted to avoid over other benefits. But there are much more elaborate mechanisms that can be done.