Forum Discussion
shaggy_121467
Cumulonimbus
@michael j has it right - data groups are probably best for dealing with matching against a large list of items or matching against a list that changes often. A few of the biggest advantages to using data groups over "if/then" or "switch" logic are readability and you should rarely have to touch the iRule itself. Adding a new hostname/pool-name pair just requires adding an entry to a data-group.
If you want to base the pool selection on the requested HTTP host header, you can try something like:
A data group with string entries of name: HTTP hostname and value: pool-name
ltm data-group internal test-dg {
records {
abc.com {
data abc_pool
}
def.com {
data def_pool
}
}
type string
}
The associated iRule:
when HTTP_REQUEST {
test-dg is a string data-group where the entries are name:value pairs
name is the requested HTTP host header, value is the associated pool-name
check the requested HTTP host header against entries in data-group test-dg
if { [class match [string tolower [HTTP::host]] equals test-dg ] } {
if the HTTP host header is in test-dg
send the request to the pool associated with the test-dg entry
pool [class match -value [string tolower [HTTP::host]] equals test-dg ]
} else {
drop the request if the host header is not in test-dg
drop
}
}
shaggy_121467
May 20, 2015Cumulonimbus
Without oneconnect, the iRule will only make a decision for the first HTTP request sent across a user's TCP connection to the VS. If the user sends multiple HTTP requests using that connection, all subsequent requests across that TCP connection will follow the iRule decision based on the initial HTTP request. From the sol article referenced below - "When a OneConnect profile is enabled for an HTTP virtual server, and an HTTP client sends multiple requests within a single connection, the BIG-IP system is able to process each HTTP request individually."
SOL7208: Overview of the OneConnect profile
skip to "Content Switching"
https://support.f5.com/kb/en-us/solutions/public/7000/200/sol7208.html