PathSuffix is being copied to target URL

Not applicable

Is it possible to remove the pathsuffix in the target URL?

I have tried to apply the JavaScript policy in the default preflow and the preflow of my proxy:

context.setVariable("target.copy.pathsuffix", false)

Also, using the AssignMessage.DisablePathCopy policy:

<AssignMessagename="AssignMessage.DisablePathCopy">
    <AssignVariable>
       <Name>target.copy.pathsuffix</Name>
       <Value>false</Value>
    </AssignVariable>
</AssignMessage>

I have reviewed this question and this question but any solution of those worked.

Is the another way to prevent pathsuffix being copied?

1 11 5,264
11 REPLIES 11

Hi

You said you included the JS policy

in the default preflow and the preflow of my proxy

That won't work. The target.copy.pathsuffix gets reset at the inception of the target flow. To set it properly, please include either of those policies in the request flow of your Target endpoint. You can choose the request preflow, request PostFlow, or a conditional flow, doesn't matter; as long as it is in the Target.

6427-service.png

Thanks for your answer, but, as you can see, I have already set the policy in the preflow target, no matter where I set that policy, it doesn't work 😞

ok I understand you're saying it's not working.

What specifically, does it mean, when you say "it doesn't work" ?

Can you give me a specific, concrete example of it not working? For example, an inbound request URL, and the corresponding outbound request URL, showing that it does not work? A Trace, perhaps?

This is a really basic feature, very commonly used. When you set that variable, it does not copy the pathsuffix. That happens successfully in thousands of proxies. You're saying "it doesn't work". So I suspect there is a missed connection somewhere, or a misunderstanding on my part or on your part.

Yes, sure. For instance:

My proxy address is something like this, where the pathsuffix of the proxy is /token:

http://1.1.1.1:8080/dynamicurl/token

The target address should be something like this:

http://otherservice.com:50000/bpm/taskdata.svc/userId/$metadata

But, reviewing the trace, I have a http error 400 because the URL is composed by "target address" + "pathsuffix", something like this:

http://otherservice.com:50000/bpm/taskdata.svc/userId/$metadata/token

The "/token" at the end causes an error consuming the target address. I don't know if this information is enough to explain my scenario and the fix that I need.

And the "dynamicurl" ... that can be any number of path segments. Is that right? does it always begin with something? Like /odata ? or ... ?

dyamicurl is the name of my proxy and no, is static, my proxy will always have the structure http://1.1.1.1:8080/dynamicurl/<name of the endopoint>. In the furute I will be adding more endpoints to my proxy, for instance, right now I have only http://1.1.1.1:8080/dynamicurl/token, but it's possible to integrate http://1.1.1.1:8080/dynamicurl/clients or http://1.1.1.1:8080/dynamicurl/vendors

ok, I understand.

The attached proxy either DOES or DOES NOT copy the pathsuffix to the request that is sent to the backend . This is an example of NOT copying.

curl -i https://ORG-ENV.apigee.net/felix-1/token 
HTTP/1.1 200 OK
Date: Thu, 08 Feb 2018 22:33:24 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 518
Connection: keep-alive
Server: Cowboy
X-Powered-By: Express
Etag: W/"206-wAlc+iNDpxeSDsm3XrHrPIGbN+Q"
Via: 1.1 vegur
{
  "url": "/bpm/taskdata.svc/userId/$metadata",
  "method": "GET",
  "headers": {
    "host": "dc-echo.herokuapp.com",
    "connection": "close",
    "x-forwarded-for": "104.132.51.110, 107.23.127.92",
    "x-forwarded-port": "443",
    "x-forwarded-proto": "https",
    "user-agent": "curl/7.56.1",
    "accept": "*/*",
    "x-request-id": "8c188e2a-d9e8-4a18-8b29-8742f2dcb104",
    "via": "1.1 vegur",
    "connect-time": "0",
    "x-request-start": "1518129204458",
    "total-route-time": "0"
  },
  "body": {}
}

This response is from an "Echo" service. It simply echoes back the data it received in request, though in JSON form. You can see the verb used, the url path, the headers, and the body. As you can see the url is "/bpm/taskdata.svc/userId/$metadata . Which I think is what you want.

This is an example of copying:

curl -i https://ORG-ENV.apigee.net/felix-1/token2 
HTTP/1.1 200 OK
Date: Thu, 08 Feb 2018 22:33:28 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 525
Connection: keep-alive
Server: Cowboy
X-Powered-By: Express
Etag: W/"20d-N26lZpfHybJ1CgjgGx1nivqn2tE"
Via: 1.1 vegur


{
  "url": "/bpm/taskdata.svc/userId/$metadata/token2",
  "method": "GET",
  "headers": {
    "host": "dc-echo.herokuapp.com",
    "connection": "close",
    "x-forwarded-for": "104.132.51.110, 107.23.127.92",
    "x-forwarded-port": "443",
    "x-forwarded-proto": "https",
    "user-agent": "curl/7.56.1",
    "accept": "*/*",
    "x-request-id": "e2c33456-b908-4e29-878f-1bc222945a02",
    "via": "1.1 vegur",
    "connect-time": "1",
    "x-request-start": "1518129208601",
    "total-route-time": "0"
  },
  "body": {}
}
<br>

As you can see the /token2 is now copied from the frontend (proxy) to the backend.

In the former case, the /token path, I have a policy that runs and sets target.copy.pathsuffix to false. In the latter case, that policy does not run.

Deploy and try yourself?

apiproxy-felix-1.zip

@Dino I have an error tryng to download the attached file "Access to the specified resource () has been forbidden"

@Dino Thanks for your help. Now it's working but in a proxy created from the scracth. I don't know why in my older proxy it didn't work. Maybe you could post/convert your comment with the example as an answer.