Hello,
I have the following problem :
I have a (soap) proxy that is redirected with 302 (for the backend defined in the targetendpoint).
The return of my proxy is correct with the content of the final backend (the one my call is redirected to) with code of 200 and the right payload.
The issue is when I look at the payload when I am in trace mode I always have the payload of the first backend (the one with 302) and so I can not use the payload returned by the proxy to do actions like validation of the content
Thanks For your Help
Bilal EL JOUZOU
Hi Bilal
Ok, I understand
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.
Hi. In a process of 3-legged implementation, I am getting a 302 http status code from the target endpoint and apigee url as below:
Please post new questions as a new question.
Also, not clear why you want Apigee to make the request, assuming the end client should be doing so?
User | Count |
---|---|
1 | |
1 | |
1 | |
1 | |
1 |