I ran across an old InfoPath form issue:
“The form cannot be submitted to the web server either because your computer is offline or because the host server is currently unavailable”
This error is known to be associated with AAM (Alternate Access Mappings). Specifically, if you are trying to view the form from a URL that is not configured in AAM, you will get this issue. My challenge this time was determine how to configure AAM to support Off-Box SSL termination:
Most of the posts I found referred to just adding an entry for the external URL. However, that doesn’t work in this context, as the Proxy is routing requests to SharePoint as if they came from http. SharePoint doesn’t know that the request was originally for https, and so any URLs that SharePoint embeds on the page will be for http.
A few posts suggesting solving this problem with link translation (Set up AAM as above, and use the link translation of the proxy to convert the URLs that SharePoint rendered on the page from http to https). I am not a proxy expert by any means, but this seems like a bad idea:
- It may make the form work, but you would also have to test every other piece of functionality on SharePoint to verify that there are no other issues. (For example, if AAM isn’t set up correctly, you’ll not only get this issue related to InfoPath forms, but you’ll have an issue when a user goes to a document library and clicks on “new” in the ribbon. The “new” button directs the user to the template file for the library. If AAM isn’t set up correctly, that will fail as well. And, the link translation that successfully corrects the InfoPath issue will not correct this library issue.) There are quite a few ways that SharePoint encodes URLs. Tracking them all down for link translation rules would be challenging at best.
- Any service pack or future product update could change how a URL is encoded, or add new functionality with new URL encodings, and you’ll be back to having issues.
- I couldn’t find confirmation of this, but I think it’s likely that MS won’t provide much support as soon as they discover that URL rewriting is happening.
The solution to this is indeed AAM (Alternate Access Mappings): configuring two different internal URLs that both have the same external URL. In the above example, the two different internal URLs would be:
Both of the above would have the same public URL:
For full screen shots and better step-by-step instructions, see: