Hi Bilal
Ok, I understand
- you have an API Proxy in Apigee, and it uses as a target, a soap service
- the response sent from the proxy to the client is correct, with a 200 OK, and the expected SOAP response payload
- a twist!: there is a 302 somewhere. Some system, somewhere, is returning a 302 Found status, with a Location header.
- Some system, somewhere, is handling that 302 and following it.
- When you use Apigee trace to see the payload, you only see the 302 Found, and you don't see the 200 OK.
Here's what I think. Apigee's target system doesn't automatically follow 302's. What I mean by "follow 302" is this: a "302 Found" response is intended to allow the server to say, "hey client, you've got the wrong address. You asked for /foo/bar but really the information you want is at /baz/boom ." More information here. Normally the server communicates the actual location of the resource with a response header named... Location. The full HTTP response might look like this:
HTTP/1.1 302 Found
Location: /baz/boom
Content-Type: text/plain; charset=utf-8
Content-Length: 23
Date: Tue, 07 Jul 2020 17:08:25 GMT
Connection: keep-alive
please visit /baz/boom
The location header may be a full URL or a relative URL. When Apigee connects to a target, and the target returns a "302 Found", Apigee doesn't do anything with that Location header. It just passes it through to the client. If it is a fully-qualified URL, then the client receives that fully-qualified URL.
Typically, clients (aka "user agents") will "follow" the redirect, meaning the client, upon receiving a 302 Found response, will make a new request to the URI designated in the Location header. The client will have made two requests, when the response to the first request is a 302 found. But here's the kicker: the 2nd request might not flow through Apigee.
Suppose the data flow is client -> Apigee -> Service, and the response from the service is like this:
HTTP/1.1 302 Found
Location: https://my-internal-service.example.com/baz/boom
Content-Type: text/plain; charset=utf-8
Content-Length: 0
Date: Tue, 07 Jul 2020 17:08:25 GMT
Connection: keep-alive
Then the client will make a new request to https://my-internal-service.example.com/baz/boom , and if that endpoint is not an Apigee-managed endpoint, then the client will connect to that bare service.
If that bare service returns valid SOAP, then... the client gets valid SOAP, and Apigee has not participated in that exchange.
Does this make sense? So I think observation #2 in my list above... is suspect. I think the client really is getting a valid SOAP response, but that valid SOAP response is not being handled by Apigee. The client is getting it directly from the redirected service.
To fix this... to allow Apigee to mediate the 2nd call (client following the 302 redirect), you would need to insert an additional policy on the response flow for the 1st call. That policy would have to rewrite the Location header to point to your apigee endpoint, rather than the endpoint of the bare service.
If you do that, the client still receives the 302, but the Location header points back to Apigee. Apigee will handle the 2nd request as well, and will have a chance to mediate the response payload.
LinkedIn
Twitter
