Abrir pdf de forma inmediata en Sharepoint – Open pdf directly

if you’ve installed SharePoint 2010, you may have noticed a change in behaviour of any PDF files that you may have stored. Previously, they would open directly in the browser, but now the user is prompted to save the file to the disk. This is due to a new security feature in IE8 that SharePoint 2010 respects.

“In Internet Explorer 8, Microsoft added a security feature to prevent script injection vulnerabilities caused by buggy client software. This feature is activated by a new HTTP header called X-Download-Options which can be set to noopen. When that header is passed with a file attachment Internet Explorer 8 will not provide the option to directly open the file, instead you must first save the file locally and then open it.

SharePoint 2010 utilizes this enhanced security feature in IE 8 to block the opening of file types it considers vulnerable to scripting or other attacks, such as PDFs, HTML, etc. You can modify SharePoint's behavior by changing the Browser File Handling option in the Web Application General Settings of SharePoint 2010. Your options are Permissive and Strict, with strict being the default.

Figure 2 – Opening a PDF in Strict mode

Figure 3 – Opening a PDF in Permissive mode
As you can see, in Strict mode, I am prompted to Save or Cancel (Fig. 2). In Permissive mode, the PDF immediately opens without being prompted (Fig. 3), and in my case, my PDFs open in the browser by default (this is a setting you can change).
Another way this issue manifests itself is when opening versions in an InfoPath form library. Someone posted this issue on the forums, and when I didn’t experience the same issue, I immediately thought of Browser File Handling. Mine was already set to Permissive, so I switched it to Strict, and I experienced the same issue. Switching back to Permissive fixed it. Here is the scenario:

Figure 4 – Form Library set to Open in the Client (not browser)

Figure 5 – Form Library set to Create major versions (max 2)

Figure 5 – Check the Version History of an individual form and click on an older version to view it

Figure 6 – Result of clicking an older version in Strict mode

Figure 7 – Result of clicking an older version in Permissive mode
As you can see, when in Strict mode, the browser views this as a regular XML file (Fig. 6) and doesn’t associate it with InfoPath like it does in Permissive mode (Fig. 7).
This change is done at the application level. First, navigate to Manage Web Application within Central Admin, select the application in question, and choose General Settings on the ribbon.
 
This change is done at the application level. First, navigate to Manage Web Application within Central Admin, select the application in question, and choose General Settings on the ribbon.

Once in the settings screen, scroll down and find the section for Browser File Handling, and change it to permissive.

 
ACTUALIZACIÓN 1
 
I just ran across a case where this does not fix the problem. PDFs and all file types including HTML were prompting the user for download. This was not consistent, as it was happening in some libraries and not others. As it turns out, it’s a bit of a bug, and document libraries will not always inherit the browser handling attribute.
You can test this by running the following Powershell:

$site = Get-SPSite(“https://mysitecollection")
$web = $site.OpenWeb("/MyWeb")
$list = $web.GetList("https://myweburl/LibraryName")
$list.browserfilehandling

If it returns “Strict”, then you have a problem. The good news is, you can set it:

$list.browserfilehandling = “Permissive” ;
$list.update();

You should probably loop through your entire site collection and set this value to be safe. The powershell to do this can be found  on Nerdtastics Tips, which is where I found the fix in the first place.



ACTUALIZACIÓN 2


As opposed to hunting through your sites to find the problems, I wrote the below PowerShell script that take the URL for the site collection as an argument, and sets the permissive flag on any lists set to strict.

Add-PSSnapin Microsoft.SharePoint.PowerShell -erroraction SilentlyContinue
$siteURL = $args[0]
$webname = $args[1]
$site = Get-SPSite($siteURL)

foreach ($web in $site.AllWebs) {
    Write-Host "Inspecting " $web.Title
    foreach ($list in $web.Lists) {
        if($list.browserfilehandling -eq "Strict") {
            Write-Host "Changing " $list.Title
            $list.browserfilehandling = "Permissive";
            $list.update();
            $site.url,
            $list.title,
            $list.browserfilehandling
        }
    }
}

ACTUALIZACION 3

SharePoint continued to prompt for download even though the BrowserFileHandling property was set to permissive at both the application and at the library level. I registered a support call with Microsoft and was told that they’ve seen this, and were working on it, and there was no expected date for an answer.
I decided to do some further experimenting, and found that I was actually running into two different things that caused this. The environment had both, so it made troubleshooting a real treat.

1. Adding the PDF icon to the front end server causes prompting for download

It’s been standard procedure since SharePoint 2007 to manually add in the PDF icon to display PDF documents, as described here. Every time that I do so, SharePoint starts prompting for download instead of opening in the browser. I as yet have no idea why,but it’s repeatable. UPDATE – This has been solved – see below.

2. Creating a site from a custom site template causes prompting for download

With the PDF icon uninstalled,the browser behaviour is correct on all sites in the site collection. If you then create a site template from an existing site with a library, and then use that template to create a new site, you will experience the prompting behaviour on any documents saved to that library. This is NOT true for any new libraries created in the site. You can also run the PowerShell script that I previously posted to reset the properties of the libraries, and they will behave properly.
For the record, the environment that I was working on this problem with was Search Server Express 2010, which is essentially the same as SharePoint Foundation plus the Search features from SharePoint Server.
Both of these problems are quite annoying, and I suspect I’ll be updating this post as I learn more, or as I hear back from Microsoft.
UPDATE
I’ve put together a solution that can be installed on a farm and activated at the site collection level. It’s essentially an event receiver that fires whenever a new web (subsite) is created and it sets all of the lists to Permissive. It works fine for me, and for at least one customer, and I provide it to you here with no warranties express or implied…. If anyone is interested in the code, let me know, but it’s only about 5 lines.
 
ACTUALIZACION 4
The pdf icon problem has been solved. I’ve been back and forth with Microsoft on this and we wound up exchanging DOCICON.XML files. They sent me back one that worked, and the suggestion was that I change the icon file name to pdf16.gif to accommodate it. However, I noticed that there was an additional attribute in their file, OpenControl=””. I added that to the Mapping tag for my PDF extension, did an IISReset, and the problem was solved. For the record, the complete tag will look like:
<Mapping Key=”pdf” Value=”pdf16.gif” OpenControl=”"/>
With pdf16.gif being whatever the name of your pdf icon file is.
Microsoft also confirmed the problem with the custom site templates that I created the solution for above. It’ll have to do until a fix is available.

ACTUALIZACION 5

Reader Christoffer von Sabsay has notified that this bug has been fixed in the December 2010 Cumulative Update Pack for SharePoint Foundation. 

For a list of the fixes in this CU, and to request them, go to http://support.microsoft.com/kb/2459108. The event receiver workaround 

should NOT be required after applying this and you should remove it upon doing so.

ACTUALIZACION 6

$webApp = Get-SPWebApplication @webURL
If ($webApp.AllowedInlineDownloadedMimeTypes -notcontains “application/pdf”)
{
Write-Host -ForegroundColor White “Adding Pdf MIME Type…”
$webApp.AllowedInlineDownloadedMimeTypes.Add(“application/pdf”)
$webApp.Update()
Write-Host -ForegroundColor White “Added and saved.”
}
Else {
Write-Host -ForegroundColor White “Pdf MIME type is already added.”
}

Command: FileName.ps1 http://your_Site_Url/

Fuentes: http://whitepages.unlimitedviz.com/, http://praveenbattula.blogspot.com, http://sareapoint.blogspot.com, http://www.sharepointedutech.com