When I send a timestamp as a query parameter, Apigee is mapping colons into %3A

[srimukundanthia]

Hello All,

Im trying to post a call via postman ,which gets process via APIGEE to internal VIP's and then reaches the Application

Postman call : https://api-dev.abcd.com/transport/m/l/xc/GetTrailerLocation?DriverID=111111&UTC=2020-07-17T10:00:00...

but when i trace within APIGEE the time parameter goes 10%3A00%3A000 instead of 10:00:00 due to which i get error in application

is someway we can overcome this in APIGEE...not sure why in apigee it converts into %3A.

If i try to process the same calls within internal VIP's it getting processed successfully.

[#2]

can you make that to header? In url its encoding happens.

[srimukundanthia]

Thanks for your prompt. The source and the Destination application works based upon the query param.

is their way to overcome ?

[#4]

you can request to apigee using headers and inside apigee using javascript or javacallout modify the header to url for the backend request.

[dchiesa1 · Accepted solution]

I think maybe you are being misled by the Trace display.

When you use Trace to view the inbound URL, it shows the encoded form.

But when I use an AssignMessage to simply READ the variable that holds the queryparam, I get the unencoded form. For example If I use this policy:

<AssignMessage name='AM-ExposeVariable'>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
  <AssignVariable>
    <Name>assigned</Name>
    <Template>{request.queryparam.UTC}</Template>
  </AssignVariable>
</AssignMessage>

..and then invoke my proxy with the same query parameters that you used, I see this in trace:

note the URL is shown encoded, the variable value is decoded. This is expected, and correct.

You also said:

due to which i get error in application

And you haven't specified what error you get. This will require further investigation on your part.

As you investigate, keep in mind the rules for HTTP applications when dealing with query parameters. HTTP Clients (like curl or postman or etc) must url-encode the query parameter values. This is why, when you try to send a timestamp that contains colons, all the colons get mapped to %3A. It is not Apigee doing that; it's the client program.

HTTP Server applications, as Apigee is with respect to curl or postman, must decode URL parameters before using them. In accordance with this rule, Apigee receives the encoded value from the client, and returns the decoded form to your proxy, when the apiproxy reads it, by accessing a variable like request.queryparam.UTC. Apigee maps all the %3A sequences to colons.

Remember: Apigee ALSO acts as a client to the upstream system, which in your case is what you have called "the application". When acting as a client, as all correct HTTP clients must do, Apigee must (and does) URL-encode the values for each query parameter. Apigee sends the query string with these encoded forms. The upstream system (now acting as the server, to Apigee's client) must decode them before using the values.

Why might you be seeing the error in your application? It's possible that your upstream system is not decoding the properly encoded query params. It's also possible that Apigee is correctly encoding the query parameters, and the upstream system is properly decoding them, and that the error you are seeing in your upstream application is unrelated to the encoding of the query parameters. Or maybe there is some other error that I can't imagine at this moment.

You will need to investigate to understand better. But all of the information you have given so far indicates that Apigee is behaving correctly, and as designed.