Issue with $ sign being url encoded when sending in target url

Google Cloud Apigee
1

Hi Guys,

I am facing an issue when sending request to backend endpoint from apigee. I have my javascript policy which sets the target url in the proxy endpoint pre flow step.

I am setting my target url which has these special characters‘$ (‘ in the request because i am filtering down the data in the backend.
context.setVariable('target.url', baseUrl + '/v3/oquery/getDataSubjectCurrent?$expand=CurrentStanddak($select=SyrenisID,Custom1,Custom2, Custom4,Forename,Surname),CurrentPreferences($select=ChannelID,ChannelName,PreferenceID,PreferenceType,PreferenceValue,IsChannelOptedIn)');

When the request is read from the javascript policy it has sets correct target url but as soon as the request is sent it encodes those $ signs. This results in the backend sending a huge payload size which is timing out in apigee and it throws 502 issue. Given the backend is an external service, I need to send the exact url without encoding, how can i do that in my target endpoint pre flow? and how can also manage huge payload response sizes?

v3/oquery/getDataSubjectCurrent?%24expand=CurrentStanddak%28%24select%3DSyrenisID%2CCustom1%2C%

2

Hi @Waleed_Bin_Asad ,

I did a bit of research, and what you’re seeing is Apigee’s default behaviour. On the egress, it percent-encodes both query parameter names and values, which is why fragments like $expand(…) arrive as %24expand%28…%29.

Under the hood, Apigee uses Java’s URLEncoder, so only the following characters are left as-is:

  1. Letters: A–Z a–z
  2. Digits: 0–9
  3. Four symbols: - _ . *
  4. Space is treated specially: it becomes + (and Apigee then normalises it to %20)

Everything else is encoded, leading to the transformation you’re observing.

This behaviour is controlled by a Message Processor configuration flag rather than per-TargetEndpoint settings conf_http_HTTPClient.urlencode.request.line=false

Two important caveats:

  1. This flag is global for the Message Processor. Unlike transport properties exposed on a TargetEndpoint (e.g. those listed here: Endpoint properties reference  |  Apigee  |  Google Cloud), there’s no per-proxy or per-TargetEndpoint to change only one proxy behaviour. Flipping it can impact other proxies that rely on the default encoding.
  2. On Apigee X and Edge, changing Message Processor flags typically requires Google Cloud Support to assess and apply. It isn’t something you can set within a single proxy configuration.

Given the potential impact, I wouldn’t recommend changing this globally. A safer long-term approach would be to raise a feature request to expose this configuration at the TargetEndpoint level, allowing control URL-encoding behaviour per target.

2 Likes
3

Thank you for the information, this really helps.