REST query on text property value with percent character results in web service internal server error

I have found a tracker item about this (133664).  It appears that there is some "special" encoding needed for some characters:

"_":        = "_u"
"%":      = "_p"
"*":       = "_a"
".":        = "_s"
"\'":       = "_q"

This has never made it to the documentation so I will look to sort that ASAP.

So it looks like your query should be "/REST/Objects.aspx?o=101&p1240=WIA+AANVULLING+20_p25".  Are you able to try that and let me know how it goes?

Regards,

Craig.

Well, it looks like it's a bug in handling of parameters in the REST API.

I've identified 7 strings with a percentage character in it and only one resolves to a (Salesforce) external Product object.

Pragmatically, I 've included a hardcoded table for these strings in my (PowerShell) resolve script to return a value without doing the REST request (which would yield an internal server error)....

Okay.  I'll test this out and raise a tracker item.  

I can replicate this and I currently believe that it's a bug.  I have raised a tracker item (160546) and added GeONE as the company that reported this.  Thanks Victor.

I can replicate this and I currently believe that it's a bug.  I have raised a tracker item (160546) and added GeONE as the company that reported this.  Thanks Victor.

I have been given a workaround.  Apparently for this to function correctly, you need to provide a HTTP header named "x-extensions" with a value of "MFWA".  This should make the decoding function correctly.

Thanks for the feedback, Craig.

I added "x-extension" header to the REST query with value "MFWA" and still the response is "the remote server returned an error: (500) internal server error".

I do the call from PowerShell script and have also the headers "X-Username", "X-Password" and "X-Vault"; I know these are obsolete, but so very convenient in this scenario for finding an external (Salesforce) id for an product object with a specific property.

Did you try "x-extension" or "x-extensions"?

This was the second try, with some capital letters

This is my first test, with the X-Extensions header commented out:

This is my second request, with the header included:

Aha, I have to apply the infamous M-Files encoding as well!

Search string: "WIA AANVULLING 20%"  (with the culprit %)

M-files encoded: "WIA_p20AANVULLING_p2020_p25"

And with the added "x-extensions" = "MFWA" header, I do get a result!

Aha, yes, I see how my response was unclear.  For the "it should work if it's encoded according to that logic" stuff to work then it needs this header.  It doesn't, unfortunately "just work" with this header.