Forum Discussion

daboochmeister's avatar
Jul 01, 2014

Local 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:

   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.

3 Replies

  • Just an FYI, I usually figure this out by making a few test cases and seeing what happens.
  • A few thoughts here.


    1. 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.


    2. 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.


  • Yeah, I just don't have access to a balancer I can test on right now - this is notional design work. But understood and agreed.