How can I expose an extra endpoint that adds a query parameter?

Not applicable

I've a proxy that forwards all requests to my target server and everything works well.

Now I want to add an extra endpoint to my proxy that is an alias of an existing one.

Let's say the original endpoint is

GET /my_original_endpoint?q=10

I want to expose an endpoint like

GET /my_alias_endpoint?q=10

that forward all request to /my_original_endpoint?q=10 but add a value in the query string. the request received by my target endpoint should be

GET /my_original_endpoint?q=10&f=20
1 4 307
4 REPLIES 4

Hi Simone

you can do this with a 2nd proxy endpoint, which "chains" to the original.

In the 2nd, "alias" proxy endpoint, attach a policy that adds a query param.

Attached is a working example.

fumagalli-1.zip

With this setup, you create a second proxy that forwards requests for

GET /my-alias-proxy/my_path

to

GET /my-original-proxy/my_path?f=20

correct ?

Is this "rule" applied to all endpoints of `my-original-proxy'?

I mean if I call

GET /my-alias-proxy/my_second_path

is rewritten to

GET /my-original-proxy/my_second_path?f=20

?

Yes, correct.

But there is one surprising part.

I just tested this further and observed that the proxy.pathsuffix variable does not get populated in the proxy handling a request sent from a LocalTargetConnection.

In other words, when I do

GET /my-alias-proxy/any_path

...the 2nd (chained) proxy actually receives this request:

GET /my-original-proxy/any_path?f=20

...but the variable "proxy.pathsuffix" is not populated in the MessageContext for that request. I would expect it to be populated with "/any_path". Therefore if the 2nd proxy calls out to a third system via HTTPTargetConnection, the path used on inbound - "/any_path" in this example - is not propagated. Instead the external target receives a path of / .

This is counterintuitive and it seems like a bug to me.

If this is a problem for you, there's an easy workaround: just forcibly set the proxy.pathsuffix in the target flow for the 2nd proxy. I would use a JS callout that does some URI parsing, before calling something like:

context.setVariable('target.url', theNewValue);

In fact I will try that right now.

ok, here's the working example.

The key bit is a JS callout in the target flow that does this:

var inboundUri = new URI(context.getVariable('proxy.url'));
var inboundPath = inboundUri.path();
var outboundUri = new URI(context.getVariable('target.url'));
var originalPath = outboundUri.segment();
var pathToAppend = inboundUri.segment();
outboundUri.segmentCoded(originalPath.concat(pathToAppend));
outboundUri.query(inboundUri.query());
context.setVariable('target.url', outboundUri.toString());

fumagalli-1-rev7-2017-06-14.zip