Getting responses from different targets - how is this possible?
I have a JS script that does some URL rewriting (via setting context variable for target.url). The script is straightforward. I'll be specific and won't leave anything out. It strips a part of the path to build the hostname.
Example:
https://api.stuff.com/customer1/items/123
rewrites to:
https://customer1.stuff.com/items/123
This has been working for the last year. However, for the last 2 months, I've been seeing weird behavior. Intermittently, a request to customer1 would get the response of a request to customer2 (I know this because the Host header of the response is that of customer2.stuff.com).
There is no response caching, so Apigee would be "stateless" as far as I know. It's just a straightforward rewrite. I do not store any of the names on Apigee or the rewrite script. So how would a request to customer1 know of a customer2?
What's even weirder is that based on the response headers coming back, the response is from a few days before. So I don't think it's a race condition/concurrency issue. I've put a lot of traffic through but cannot reproduce on-demand. It's rare, but it happens.
Any thoughts?
Answer by Dino-at-Google
·
Jan 09 at 11:48 PM
It's possible for the problem to not be in your code, or in Apigee. It could be that the virtual-IP that sits in front of "customerX.stuff.com" is misconfigured or misbehaving.
In other words, the upstream firewall might receive a request on "https://customer1.stuff.com" and it might route it incorrectly to a system for customer2. Or something analogous to that.
A second possibility I can imagine is that there is a cache somewhere. Either in Apigee, or behind it (between Apigee and Upstream) , or in the upstream system. And that cache is using an incorrect cache key.
Interesting thought. I'll try to look for something like that. Thanks!
