Connect REST query string parameter encoding not working for semicolon
I have a requirement to send a query string parameter that includes semicolons to separate values like so:
https://endpoint/getInfo?propertynames=propname1;propname2;propname2
I am encoding the parameter using the function @encodeURLParameter and I can see in the tracer that this is working and on the connect rest rule I have also set Content-Type header to be application/x-www-form-urlencoded.
However when the endpoint receives the request the querystring parameter is no longer encoded and the semicolons are in plain text.
Pegasystems Inc.
US
"when the endpoint receives the request the querystring parameter"
How are you reading the query string parameter that the endpoint received? The endpoint is expected to URL decode the query string before use, so that may be what you are seeing.
Liberty Global Europe Ltd
IE
Hi HOULJ, thanks for your response but no the request is arriving at the endpoint already decoded. We have examined the logs from the receiving endpoint and the URL does not have the semicolons encoded when the request arrives.
Pegasystems Inc.
US
Okay, but there is still a chance that the logs on the endpoint will show you the URL as it was interpreted by the endpoint, so the decoding would have already taken place by the time you are seeing it in the logs.
Pegasystems Inc.
US
While we're on the topic... if the Pega side says "one;two;three" why is it a problem that the endpoint is seeing "one;two;three" when it gets the query string?
Any encoding that happened in-between was to keep the values safe/appropriate for transfer.
I am having trouble understanding what part of this situation is problematic for your use case.
Updated: 30 May 2018 3:53 EDT
Liberty Global Europe Ltd
IE
We are calling into a commercial API platform that will not accept any un-encoded characters for security reasons and it strips off everything after the first un-encoded character it encounters.
regards,
John
Liberty Global Europe Ltd
IE
We have confirmed that is not the case by testing the behavior from another client that is not Pega and URL is received by endpoint encrypted and is shown in endpoint logs as encrypted so this indicates that the issue is with Pega and not the endpoint.