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?

0 2 132
2 REPLIES 2

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!