Most internet users are accustomed to opening PDF files in the browser or clicking a link and having Adobe Reader open the file. In either case, you click a link and the PDF opens, no issues. In SharePoint 2010 this may not be the case. Since PDF files represent a security risk, SharePoint adds 'X-Download-Options: noopen' to the header when downloading a PDF stored in a library. This tells the browser not to open the file, but rather save it to disk, thus not presenting the user with an 'Open' option. SharePoint will add this to any file it deems a security risk, not just PDFs, although they usually come up first in this discussion.

Now that we know the cause, how do we fix it. There are two ways to solve this issue, the correct way and the wrong way. A quick Google search for this problem and 99.9% of the solutions tell you the wrong way. Let's take a look at both options.

Option #1 - The wrong way, changing "Browser File Handling" from Script to Permissive

A web application has a setting in Central Administration called "Browser File Handling", which offers two settings: Permissive and Strict.

From TechNet: "You can specify whether additional security headers are added to documents that are served to Web browsers. These security headers specify that a browser shows a download prompt for certain types of files (for example, .html), and to use the server's specified Multipurpose Internet Mail Extensions (MIME) type for other types of files."

The Strict setting will add the noopen to the header of any document being downloaded whose MIME type is not in the allowed list for the web application (.pdf being one of them).

The Permissive setting will not add the noopen to any document being downloaded.

Strict is set as the default as it represents the least amount of risk. Changing this to Permissive opens a large security hole in your environment and in most cases is not needed or recommended.

Option #2 - The correct way, adding the PDF extension to the allowed MIME type list

Fortunately, we have another option which keeps the security of Strict file handling in place, but allowing PDFs to be added to the allowed MIME type list and open in the browser.

With a little PowerShell we can easily add the PDF MIME type to the web application's AllowedInlineDownloadMimeTypes property:

$webApp = Get-SPWebApplication("http://yourwebappurl")
$webApp.AllowedInlineDownloadedMimeTypes.Add("application/pdf")
$webApp.Update()

Once you have run these commands, you can call the AllowedInlineDownloadedMimeTypes again to get a list of all MIME types it contains:

$webApp.AllowedInlineDownloadedMimeTypes

You should see "application/pdf" at the bottom of the list. The newly added MIME type will not be in alphabetical order and will always be last in the list. Now, surf to your web application and try to download a PDF. You should now have an "Open" option that was not there before.

Use Option #2!

As you can see, adding PDFs to the allowed MIME type list of your web application is quick and easy. This allows you to give your users a familiar and expected experience, all while maintaining good security practices and keeping other file types under the Strict browser file handling setting.