How to handle Query params with special characters
Hi folks,
I want to pass the comma separated query paramerters to the target endpoint url, hence i have tried to do it with below mentioned 2 ways.
1. In Proxy Endpoints Preflow, Tried to get the params from the request url and set the Query params via Assign Message policy in order to pass it as a query params to the target endpoint url
2. In Target Endpoints Preflow, Tried to get the params from the request url inside javascript and made a new target url there by embedding comma separated query params to the target endpoint url and further assigning it to the 'target.url' apigee variable.
I'm yet unable to hit the target url properly because while apigee hits this new target url, it replaces query param commas with %2C
eg. https://hostname:port/basepath?q=q1,q2,q3
getting converted to
https://hostname:port/basepath?q=q1%2Cq2%2Cq3
Because of the above change not getting the desired response as backend is not able to resolve %2C%2C.
Can anyone pl help here?
Answer by Dino
·
Nov 24, 2015 at 02:37 AM
Unfortunately it seems you are running into a particularly grey area in the W3 specifications.
The spec for form submission states that, for GET requests, all data is encoded using the "application/x-www-form-urlencoded" content type. And further, that means:
Control names and values are escaped. Space characters are replaced by `+', and then [1] reserved characters are escaped as described in [RFC1738], section 2.2: [2] Non-alphanumeric characters are replaced by `%HH', a percent sign and two hexadecimal digits representing the ASCII code of the character. Line breaks are represented as "CR LF" pairs (i.e., `%0D%0A').
That paragraph provides all the grey fuzzies you need to get into trouble. The sentence marked [1] above says that "reserved characters are escaped as described in RFC1738". And the sentence marked [2] above says "non-alphanumeric characters are replaced by %HH".
Considering the above, Should the comma, when part of the value of a query param, be encoded as %2C or not? Not clear. In the first place, the comma is not "reserved", and the first sentence above suggests that it need not be encoded. In the second place, the comma is non-alphanumeric, and the 2nd sentence seems to require that it be encoded. Fuzz!
Where are we to turn when the rules are fuzzy? The next best thing is de-facto standards.
The default behavior of modern browsers such as Chrome and Firefox is to encode commas when they appear in values of query params. Likewise the behavior of the Javascript built-in function, encodeURIComponent(), which is used in jQuery and other browser-side ajax frameworks.
The behavior of Apigee Edge is to do the same.
One might argue, "it's not necessary to encode commas!" But one would be arguing with a very large portion of the internet.
The safest thing, then, is to call decodeURIComponent() or the equivalent, on all received query strings, within your server.
In other words, your backend needs to tolerate encoded commas when they appear in the values of query params.
