Could not open "https://..../Forms/template.xsn"

[Brian Carnes]

Can an InfoPath form be accessed from an intranet as well as secure extranet?

We have SharePoint intranet site with a form at
"http://.../Forms/template.xsn". The same SharePoint site (and form) is
accessible at "https://...../Forms/template.xsn" to employees not signed into
VPN.

Using save functionality, I am able to add a form to the library from either
http or https. But when I visit the external site (https://...) and open a
form created from the internal site (http://), I get "Could not open
http://...../Forms/template.xsn". Visa Versa. The form saves ok though.

The test form is using jscript, but would like to get it to work using
managed code.

Is there a way to suppress the error?
Is it possible to make the open/submit functionality work in this situation?

Thanks, Brian

 

[Anuma]

Hi,
Add your site address (“http://.../Forms/template.xsn".) to local intanet by
using Tools/Internetoptions/Securoty/Local Intranet. Then open your site
(“http://.../Forms/template.xsn") and fill out the form.

I hope this will help you,

Thanks.

 

[Brian Carnes]

Thanks for answering, Anuma. I've already done that though.

What is unusual about the situation is that I open the form from our
extranet at https://.... But I published the form to the intranet url,
http://..., and since the template url is hardcoded into the form, it is
failing to open for extranet users.

 

[Leon Baudewijns]

Hi,
I've the exactly same problem. Also I want to publish my Form on https.
Intern the form is published on http.

Has anybody a good solution for this?

Leon


"Brian Carnes" schreef:

 

[Brian Carnes]

shirazcupala replied:
(http://www.infopathdev.com/forums/topic.asp?TOPIC_ID=2300)
The problem in this situation is that the XSN being used in each case really
looks different to InfoPath. One is on http and one is on https. Given your
environment, the only way to get around this would be to write server code to
do the PI fixup translation on the fly when the user requests the XML file.

The primary workaround is for all users to access via https (even when on
VPN).