Imported Google Group message. Original thread at: Redirecting to Google Groups Import Date: 2016-01-19 21:33:20 +0000.
Sender:Léo Lima.
Date:Thursday, 3 December 2015 14:03:06 UTC.
Is there a way to redirect requests to different URLs based on a header value with Tyk?
I managed to change the path-portion using a middleware, but I need to be able to change the entire URL.
Imported Google Group message.
Sender:Martin Buhr.
Date:Thursday, 3 December 2015 14:57:35 UTC.
Hi Leo,
I see - that’s a tricky one. Target switching isn’t supported at the moment, you’d need a separate API on the same domain with a different listen_path to target different machines, but that wouldn’t give you the same base URL.
You could try something deeply insane:
Set up three APIs: One that points at the Tyk gateway (it reverses on itself) - lets call this the Splitter API, One that points at your machine set A and one that points at Machine set B
In the first API, you set up rewrites that take a meta_data value associated with the User Session (their token data), just make it something like target_path and make the value the listen path of either Machine Set A or B.
Then you can use a custom middleware component on the Splitter API to rewrite the path to the listen path of API A or B based on this meta data value.
Basically what would happen is, users would target the splitter with their keys, which would then route their traffic via one of the two other APIs based on some value associated with their token, all inside Tyk, proxying the proxy.
You could go a step further and set this first API to not track analytics so you have only stats or A and B in your dashboard.
I really have no idea if that would work, but it would be awesome if it did 
Cheers,
Martin
Imported Google Group message.
Sender:Léo Lima.
Date:Thursday, 3 December 2015 14:13:38 UTC.
Hi Leo,
At the moment the URL rewrite only handles the path portion, not the target, and the tear get is fixed to the API in question.
I’m assuming you want to be able to change the target dynamically as well as the path portion?
May I ask about the use case?
Cheers,
Martin
Imported Google Group message.
Sender:Martin Buhr.
Date:Thursday, 3 December 2015 14:41:33 UTC.
Hello Martin,
We have a few production machines running an application. One of the machines responds to a range of clients, while the other machines are dedicated to specific clients.
We want to be able to redirect the clients requests to the right machines based on their identification. But we want to abstract that from clients and offer a single base address for all of them.
Thanks
Imported Google Group message.
Sender:Léo Lima.
Date:Thursday, 3 December 2015 14:57:35 UTC.
Hi Leo,
I see - that’s a tricky one. Target switching isn’t supported at the moment, you’d need a separate API on the same domain with a different listen_path to target different machines, but that wouldn’t give you the same base URL.
You could try something deeply insane:
Set up three APIs: One that points at the Tyk gateway (it reverses on itself) - lets call this the Splitter API, One that points at your machine set A and one that points at Machine set B
In the first API, you set up rewrites that take a meta_data value associated with the User Session (their token data), just make it something like target_path and make the value the listen path of either Machine Set A or B.
Then you can use a custom middleware component on the Splitter API to rewrite the path to the listen path of API A or B based on this meta data value.
Basically what would happen is, users would target the splitter with their keys, which would then route their traffic via one of the two other APIs based on some value associated with their token, all inside Tyk, proxying the proxy.
You could go a step further and set this first API to not track analytics so you have only stats or A and B in your dashboard.
I really have no idea if that would work, but it would be awesome if it did
Cheers,
Martin
Imported Google Group message.
Sender:Martin Buhr.
Date:Friday, 4 December 2015 12:14:38 UTC.
Wow, that actually worked!
Thank you very much!