7 Replies Latest reply on Sep 3, 2012 6:56 PM by JohnDCCIU

    Record Import via XML doesn't work with HTTPS/SSL

    JohnDCCIU

      Summary

      Record Import via XML doesn't work with HTTPS/SSL

      Product

      FileMaker Pro

      Version

      11.0v3

      Operating system version

      Mac OS X 10.6.7

      Description of the issue

      The Import Records function for XML data fails if either URL (XML or XSL) is an HTTPS (SSL) URL.  This is a serious and strange limitation, since much XML data is confidential and must be protected via SSL.

      Furthermore, this serious and non-obvious limitation is not noted explicitly anywhere in the documentation or online help that I can find.

      Even worse, if you try to use an HTTPS URL, FileMaker returns a generic and useless "unable to open primary document entity" error, rather than a useful "this function does not currently support HTTPS/SSL URLs".

      Not sure if this is a bug or just a design flaw, but it needs to be fixed to use SSL/HTTPS URLs....it's a necessity and there's no good reason not to support it.

      To ensure that this was actually the issue causing this problem, I took an identical XML file and put it on my local webserver in a straight HTTP site:  it worked fine.  I then moved the XML file to our HTTPS site and it broke the Import Records function.

      Steps to reproduce the problem

      Try to use an HTTPS URL for XML import (either manually via File/Import Records or via the Import Records script step) and watch it fail with a non-specific "unable to open primary document entity" error.

      Expected result

      HTTPS/SSL URLs SHOULD work in this context

      Actual result

      HTTPS/SSL URLs DO NOT WORK in this context

      Exact text of any error message(s) that appear

      "unable to open primary document entity"

      Configuration information

      NA

      Workaround

      On Mac OS X, you can script a shell-based "curl" statement to download the XML via HTTPS and save it to a local file on disk, then use that local file for the Import Records.  Doing that is a pain in the neck, breaks cross-platform compatibility, and it shouldn't be required.

      I'm not sure how you'd work around it on Windows.