1 Reply Latest reply on Jul 7, 2013 10:24 AM by disabled_JustinClose

    Insert From URL Un-encodes some encoded values



      Insert From URL Un-encodes some encoded values


      FileMaker Pro


      FMPA 12.0v3

      Operating system version

      Mac OS 10.8.3

      Description of the issue

      When you're sending data to a Web Service using the Insert From URL step, you need to encode the data using GetAsURLEncoded first.

      However, the script step is modifying the encoded data before sending it to the server, and this can either cause data issues or break the url.

      For example this string :


      contains 2 fields.  One is "abc" and the other is "abc&def" but encoded to %26.  But the value that FMP is sending to the server is actually


      Meaning that field2 gets the wrong value, and there's likely an issue with the non-existent "def" field.

      FileMaker also unencodes commas and @ symbols.

      Steps to reproduce the problem

      Generate an Insert URL Script step from field data with &, @ or commas.

      Check using a tcp dump tool, or server side logs to compare the calculated request with the request that fmp sends.

      I can generate sample urls that you can send dummy data to if you'd like.

      Expected result

      FileMaker shouldn't alter the url before sending it, all encoding is the job of the developer.

      Actual result

      FileMaker modifies the url before sending it, but only for some values.

      Exact text of any error message(s) that appear


      Configuration information



      If you do not run the Web service at the other end, then there is no workaround until it's fixed.

        • 1. Re: Insert From URL Un-encodes some encoded values


                   I also just recently ran into an issue similar to this:  I have sent data (script parameter) via an FMP URL, some of which was encoded, and the data was getting unencoded before being passed to the script. I wouldn't be surprised if it is the same part of the FM engine that is processing the two parts.

               In my case, I was manually encoding the data to HTML standards before hand in order to avoid having these characters show up in the end data.  But since it is automatically being decoded, I end up with those characters anyway.  Grrr.  I have had to slightly alter my encoding to avoid this problem.

               --  J