Hi,
Greeting to the community!
I’ve encountered an issue with Apigee X platform where the request urls are getting encoded incorrectly.
Example request I tried from postman is : GET https://api.xyz.com/example?test=123+abc
The url seems to be consistent in Load Balancer logs, and as soon as it reaches Apigee X, in trace session logs, I see it is encoded as https://api.xyz.com/example?test=123%20abc instead of https://api.xyz.com/example?test=123%2Babc .
Which is then forwarded incorrectly to the target server.
I’m currently not sure if this is due to Apigee or do I need to add some additional property in proxy configuration. Have anyone faced a similar issue and any possible resolution for the same?
Thanks,
Hello,
Try to encode a URL before send it to the API to ensure that special characters within it are transmitted over the internet in a format that is safe and compliant with URL standards.
URL Encoding is a form of data encoding that is used in API calls to pass data within a query string. It is used to ensure valid URLs and data are passed between web applications and the server.
Original: https://api.xyz.com/example?test=123+abc
Encoded: https://api.xyz.com/example?test=123%2Babc
1 Like
The IETF standard regarding encoding characters within query strings with HTTP urls, is… maybe not easily discoverable . The relevant spec is RFC 3986.
Section 2.2 of that specification says that plus characters must be % encoded, if you want to transmit them.
It seems like you want to transmit a plus, not a space. So percent-encode it before you send it.
This is correct behavior, based on what you’re telling me.
BTW, this is the advice Gemini has to offer on the subject:
1 Like
@dchiesa1 ,
Thank you for your response.
URI encoding on the client side is definitely an option but isn’t it clear that Apigee is encoding the url incorrectly for plus(“%2B” “+”) as space(“%20” " ").
Rest all the mentioned sub-delims in the client request such as “$” and “&” are correctly encoded by Apigee.
