Website Redirection and pool allocation

There a few problems with the above iRule:

 

 

1. if { "[HTTP::host][HTTP::uri]" contains "/target1" } { - You are evaluating the URI so you really only need [HTTP::uri]:

 

 

if { [string tolower [HTTP::uri]] starts_with "/target1" }

 

 

 

2. You have a redirect and pool statement in the same stanza. A redirect issues a 302 response to the client, telling it to go somewhere else, so the pool statement is never evaluated.

 

 

 

3. In your redirect you're essentially sending the user back to "/", so when they return you've lost all context to where they should be going (based on where they came from). If you're redirecting all users to the same host ("domain.de") and URI ("/"), how will the F5 know what the request is intended for? The URI-based redirection you're using would work if the applications lived under these static URIs, but they don't.

 

 

Ultimately you need a client side way of distinguishing a request. Clients can generally handle URIs, cookies, hosts, and other things (as long as they're consistent). Here are few options:

 

 

 

a. Host name - by far probably the easist, if you can separate the applications into different hostnames, even if using the same VIP, that would make things much simpler.

 

 

b. If users don't flip back and forth between /target1 and /target2, you could set a cookie in the initial response and traffic persistence that way.

 

 

c. ProxyPass and VIP-targeting. It's a stretch, but it could potentially work.

Hi,

 

thanks for the response.

 

 

I used persistence basend on the source address.

 

 

But I did not really understand how to modify the uri http://domain.de/target1

 

target1 is my identifier, but the member can only handle http://domain.de/

 

Do I have a chance to rewrite the answer to http://domain.de/target1 on the client?

 

 

The next step is (because of this I tried it with redirection) that if target1 sends a 302 the request should redirect to target2.

 

Do you have an iRule example which match, more or less, this requirement?

 

 

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.