Forum Discussion
daboochmeister
Cirrus
CirrusLocal Traffic Policy for complex URI transform; order of eval relative to iRules
New to 11.4, and getting my hands around Local Traffic Policies.
I have a scenario in which I evaluate starts-with against the URI, and depending on value, select a pool. But for certain URIs, I also change the URI in a non-trivial manner. For example:
when HTTP_REQUEST {
if {[HTTP::uri] starts_with "/MP"} {
pool pool1
} elseif {[HTTP::uri] starts_with "/MA/2.00"} {
HTTP::uri [string map {"/MA/2.00" "/MA"} [HTTP::uri]]
pool pool2
}
}
First – how do I do that URI transformation with a Policy? Target: http-uri has parameters of path, query-string and value. Can I just select “value” and add “[string map {"/MA/2.00" "/MA"} [HTTP::uri]]”? I mean, does an action get evaluated that way, such that you can use TCL string functions and data class references?
As an alternative, I considered using the Policy to select a pool (easy to do), and leaving the URI transform as a smaller, simpler iRule – but which gets run first, the Policy or the iRules? If the iRule went first, it would prevent to Policy "URI starts-with" condition from being met, because the URI would have been changed to not match, and no pool would get selected.
Sorry if this kind of thing is clarified somewhere – I couldn’t find it if so.
Kevin_Davies_40Nacreous
Just an FYI, I usually figure this out by making a few test cases and seeing what happens.- Kevin_Stewart
Employee
A few thoughts here.
-
A policy will route traffic based on the URI, and a rewrite profile will remap the URI. The two of these will work together, but consider that you're now managing TWO configuration objects. Also, the rewrite profile (at least in 11.5) has this odd little nuance where URIs have to end with a "/", which in this case doesn't seem like what you need.
-
I tested it, and as my instinct suggested, using the policy for routing and iRule for mapping will also work. It's less of an order of operations thing than a "bucket theory" sort of thing, but I won't dive into the details here. Suffice it to say, it should work, but then again you're now managing TWO configuration objects instead of the one (simple) iRule.
You can certainly use a policy and rewrite profile/iRule to achieve what you're looking for, but I personally would stick with the much simpler to manage single iRule for all of it.
-
daboochmeisterYeah, I just don't have access to a balancer I can test on right now - this is notional design work. But understood and agreed.
