I have a problem I have never seen before in SharePoint 2010. I created a document library workflow which runs and sends notifications (emails) to its participants. The emails contain some text and a link to document (Microsoft Word Document) which is stored in the document library.

When the participant(s) open the document from email by clicking on that link, the document looks fine (When they save and review, there are 2 buttons, Edit this Task and Edit this Document) on Microsoft Word. There is also no problem when participant tried to open the document directly via document library.

But when the participant(s) tried to open the document via Tasks List, the Edit this Document button is not showing in Microsoft Word. I've already checked the URL which refer to the document in email, document library, and tasks list, and all of the URLs are the same URLs.

I've also checked the permissions of the participants (which is sufficient), and also tried to open that document with account which has full control permission, and even site collection administrator, but the same thing happened.

Were there anyone facing the same problem? And what is the cause and solution to this problem?


2 Answers 2


Probable Cause:

SharePoint 2010 implements a new security feature called 'Permissive or Strict browser file handling'. Each type of file delivered from a web server has an associated MIME type (also called a “content-type”) that describes the nature of the content (e.g. image, text, application, etc). Internet Explorer (IE) has a MIME-sniffing feature that will attempt to determine the content-type for each downloaded resource. For Office files, if the Content-Type sent by the server is not found in the MIME database in the registry of the client machine, IE "sniffs" the MIME content types to see if there is another similar MIME type in the client machine's MIME database and will open the file using the similar MIME type. However, Strict browser file handling is enabled on each web application in SharePoint 2010 by default and this disallows the sniffing of Content-Types, so if no exact match of the Content-Type sent in the server response is found in the client's MIME database in the registry, the file will open from the Temporary Internet Files of the client machine instead of being opened from the server. MIME-sniffing also can lead to security problems for servers hosting untrusted content. For example: When opening a .docx file from a hyperlink that points to a document located in a SharePoint 2010 document library, the Content Type sent by the SharePoint 2010 server in the response is "vnd.ms-word.document.12" along with a header "X-Content-Type-Options: nosniff" which looks like this:

HTTP/1.1 200 OK Content-Length: 108 Date: Day, [Date and Time] GMT Content-Type: vnd.ms-word.document.12 X-Content-Type-Options: nosniff

Since this exact content type is not present in the MIME area of the registry of the Office client computer and no MIME sniffing will be done, the document opens from the Temporary Internet files.


There is a KB article explaining this issue by Microsoft. You can find it here: KB Article

  • Thanks user2264989, I will give it a try and tell the results. Jan 8, 2015 at 5:50

Problem solved,

The issue is caused by checkout document option from document library settings, which is misconfigured by one of our team member.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.