Problem opening an attachment from Infopath 2007 form in SharePoint 2010

Question

I have an InfoPath 2007 form that is opened as a web based form in SharePoint 2010 that has an attachment control.  In Windows XP with IE 7 when you double click the attachment there is a warning message presented and after you click OK you get a prompt that asks if you want to open or save the file or cancel.  In Windows 7 with IE 8 when you double click the attachment there is a warning message presented and after you click OK you get a prompt that asks if you want to save the file or cancel, no open option.  I already set the SharePoint browser permission to permissive for the site and it doesn't help.  How can I get this to work in Windows 7 and IE 8?

Answer 1

If it's a browser form, and you're using SharePoint 2010, is there a reason you can't conver the form to a 2010 browser form?  YOu'll gain tons of functionality and won't lose anything.  The only concern would be if it had custom code.  The reason I ask is I haven't had any issues like this in any browser on my 2010 browser forms that have attachments, but I don't have a scenario where I'd have a browser 2007 form using SharePoint, because the first thing I'd do is convert it to a 2010 form to gain all the awesome functionality.

So, I don't know why that's happening, and I know it doesn't happen in a 2010 form, so consider the option.

---

SharePoint Architect || Microsoft MVP || My Blog
Planet Technologies || SharePoint Task Force

Answer 2

I am having the exact same issue. Some of my user community is a bit annoyed with me.

I can add the following tid bit of information to the issue though. It doesn't seem to matter which operating system the person is using, but seems more browser specific. Anyone with IE 7 seems to still get the 'Open' option, where as anyone running IE8 or the IE9 beta can only 'Save' or 'Cancel'.

Answer 3

I am having the exact same issue. Some of my user community is a bit annoyed with me.

I can add the following tid bit of information to the issue though. It doesn't seem to matter which operating system the person is using, but seems more browser specific. Anyone with IE 7 seems to still get the 'Open' option, where as anyone running IE8 or the IE9 beta can only 'Save' or 'Cancel'.

My same question applies if you don't mind.

---

SharePoint Architect || Microsoft MVP || My Blog
Planet Technologies || SharePoint Task Force

Answer 4

I don't mind.

The old form uses the contact selector, and I would have to change the schema to use the people / group selector. Not really a show stopper as I could leave the old form published and just add the new version.

But, I have created a new 2010 browser form, and published it to a test site, and it displayed the same behavior, so I don't think it is specifically related to whether it is a 2007 vs. a 2010 version.

I can also open the attachements if I don't use Internet Explorer as the browser, but we use that as the default across the corporation.

Answer 5

The schema is the same for both.  They use the exact same data schema, so it shouldn't be too rough.

You say 2010 still displays this behavior, but the OP said his 2010 tests didn't.  I don't get any issues in my 2010 environments using 2010 forms.  I use IE8 and FireFox 3.6.

---

SharePoint Architect || Microsoft MVP || My Blog
Planet Technologies || SharePoint Task Force

Answer 6

All I can say is that is the behavior I am seeing. I don't see where the original poster said that this behavior did not occur on a 2010 web form.

Answer 7

Thanks, I suppose when I first tried to help, I immediately went and tested with 2010 forms on my environment, and they didn't behave this way, so my assumption was that it was only caused when using a 2007 form within 2010 Forms Services.  You are saying that you see the same behavior regardless of the form version?

Is your web app set to Permissive for files?

I only use IE8, and it doesn't happen to me, so if you have Permissive set, and it still happens in IE8 on any OS (my testing was on Win7 and W2K8R2, both 64-bit), then it would make me think it's related to security settings in IE8.

---

SharePoint Architect || Microsoft MVP || My Blog
Planet Technologies || SharePoint Task Force

Answer 8

Yes I have the web application set to permissive.

Interestingly enough, this worked just fine prior to upgrade from 2007 to 2010 no matter which version of IE was in use, and has worked for almost 4 years.

I also tried this on a different farm (test environment) and had the same issue there.

I am in agreement though that there must be a setting somewhere perhaps in the browser settings that will allow this to work. I tried changing the 'Open Files Based on Content Type not Extention' but that had no effect. I thought perhaps someone else had run into this and had figured out what needed to change.

I will continue to experiment as time allows.

Answer 9

We're experiencing the same issue. 

So far, it looks to be an issue in IE8 and greater.  IE7 across multiple platforms works fine, as does Firefox, while IE8 and IE9 won't allow documents to be opened in the browser.

I tried changing security to low and adding the site to local sites with no change.  The site is already set to permissive, etc.

 

Answer 10

How can you mark this as answered? No answers have been supplied, only suggestions which did not work.

Answer 11

Tom, but this is not your thread.  It's "answered" status is not related to whether it fixes your problem or not - only the OP - and we have not determined if you have the same problem as the OP, nor has he returned, so it's standard practice to mark it as answered, since the OP abandoned it, and the given answers work MOST of the time. This same thread has come up multiple times, and it was always the web app Permissive setting. You may have an isolated issue not related to the original poster.  The answers given are correct for the original question, but your question is an add-on, and you have an upgrade in the mix that the OP did not mention.  That warrants this thread being marked as answered, since the OP hasn't come back, and your question being set as its own, separate thread.

Those really should be the answers, but if it's still not working for you, then I really need you to try what I suggested.   YOu say you already set the web app to permissive for files, so we're left to think it's related to your IE8 security settings OR an issue with the upgrade.  Have you tried publishing a new 2010 form to a NON-upgraded SharePoint 2010 site?  Earlier, you said a new 2010 form exhibited the same behavior, but we were left to guess you tried it in the same upgraded farm.  If it also does this on a new 2010 farm with a new 2010 form, then it has to be the browser, because this hasn't happened to me in a year+ of building 2010 farms and 2010 forms.  I only use IE8 + Firefox 3.6 + Safari - it works great in all of them. 

---

SharePoint Architect || Microsoft MVP || My Blog
Planet Technologies || SharePoint Task Force

Answer 12

Clayton, I realize this is not my thread, but in order to avoid starting another one, I just was just posting in one where the same behavior was reported. I also haven't seen anyone post that the given suggestions worked, and they have not for me.

I have tried the suggestions, I have even published 2010 forms to non-upgraded sites, and different farms without it changing the behavior. I had stated that I had even tried it in a different farm with the same results, but I neglected to state that some of these tests were on non-upgraded applications for which I appologize, but they were.

Answer 13

I have run a trace on the requests for both a pdf stored in a document library, and a pdf stored as an attachment in an InfoPath form. This is what I found:

PDF stored in a document library which opens in the web browser:

 Opening library document:

HTTP/1.1 200 OK

Cache-Control: private,max-age=0

Content-Length: 295455

Content-Type: application/pdf

Expires: Mon, 01 Nov 2010 14:25:27 GMT

Last-Modified: Thu, 26 Aug 2010 21:23:00 GMT

ETag: "{BB350A38-41C0-41C2-B406-49D3AEE4424D},5"

Server: Microsoft-IIS/7.5

SPRequestGuid: 29b74c6e-7cca-43ce-a9e2-5f50c9435f03

Set-Cookie: WSS_KeepSessionAuthenticated={530fb5f7-8343-43dd-87a8-7a332a2bb749}; path=/

X-SharePointHealthScore: 1

ResourceTag: rt:BB350A38-41C0-41C2-B406-49D3AEE4424D@00000000005

Public-Extension: http://schemas.microsoft.com/repl-2

Set-Cookie: WSS_KeepSessionAuthenticated={530fb5f7-8343-43dd-87a8-7a332a2bb749}; path=/

Persistent-Auth: true

X-Powered-By: ASP.NET

MicrosoftSharePointTeamServices: 14.0.0.4762

Date: Tue, 16 Nov 2010 14:25:27 GMT

Opening InfoPath form attachment:

HTTP/1.1 200 OK

Cache-Control: private

Content-Type: application/pdf

Expires: Thu, 18 Nov 2010 14:30:42 GMT

Server: Microsoft-IIS/7.5

SPRequestGuid: ce66e130-64a4-4c9b-8dc0-72a821e42594

Set-Cookie: WSS_KeepSessionAuthenticated={530fb5f7-8343-43dd-87a8-7a332a2bb749}; path=/

X-SharePointHealthScore: 1

Content-Disposition: attachment;filename="Cent-5027-20101019-111709.pdf"

X-Content-Type-Options: nosniff

X-Download-Options: noopen

X-AspNet-Version: 2.0.50727

Set-Cookie: WSS_KeepSessionAuthenticated={530fb5f7-8343-43dd-87a8-7a332a2bb749}; path=/

Persistent-Auth: true

X-Powered-By: ASP.NET

MicrosoftSharePointTeamServices: 14.0.0.4762

Date: Tue, 16 Nov 2010 14:30:42 GMT

Content-Length: 28681

As you can see in the InfoPath form attachment, the server is inserting the HTTP header X-Download-Options: noopen. It is my understanding that by setting the Web Application General setting for browser file handling to 'Permissive' that SharePoint will allow opening a file directly from SharePoint by not adding these new security headers. This works for documents stored directly, but is not working at least for me and obviously for some others when the document is embedded in an InfoPath form. There is no setting that I am aware of on the client side to disable or ignore these headers.

Oh, and the list itself is set to permissive. I double checked by running a PowerShell script.

Answer 14

I just found this hotfix from Microsoft directly related to this issue.

http://support.microsoft.com/kb/2436035 

I just tested this hotfix on my test environment and it worked.