Website Redirection and pool allocation

The issue isn't so much about persisting to a specific server (ie. source address persistence), but rather distinguishing client side requests. HTTP is a stateless protocol, so every client request is a separate and unique transaction, and things like URIs, host names, cookies, and headers are all techniques used to understand the client's intentions. So, if you have TWO applications running on the same VIP (in different pools) that essentially share the same URI patterns, you have to find some method to differentiate the two. For example.

 

 

1. User 1 makes a request for "http://domain.de/target1" and you redirect (via 302 response) that user to "http://domain.de/".

 

2. user 2 makes a request for "http://domain.de/target2" and you redirect (via 302 response) that user to "http://domain.de/".

 

 

When either user returns to access "http://domain.de/", how do you know what they really want if the URIs are the same? You can't really base it off of the previous request because that was a separate transaction in a stateless protocol.

 

 

- You could inject a cookie to the client on its initial request to "/target1" or "/target2" so that you each subsequent request could be identified, but that wouldn't allow a user to switch back and forth between applications in a single session.

 

 

- You could (potentially) use a VIP-targeting and ProxyPass type solution to rewrite each request and response, but that would be somewhat complex.

 

 

- You could reformat the applications so that they physically lived behind unique URIs. That would make the load balancing easier, but it may cause problems with the application if it doesn't like the new URI pattern.

 

 

- And you could simply make each application its own host name that resolves (via DNS) to the same VIP address. This would be the easiest solution of all.