Irule not working as expected

Question

I created an irule when CLIENT_ACCEPTED {
    set default_pool [LB::server pool]
}&nbsp;
when HTTP_REQUEST {
    switch -glob [string tolower [HTTP::uri]] {
        "/customerdetails" -
        "/webofferlist" -
        "/membershipedit *" {
            pool poolB
        }
        default {
            pool $default_pool
        }
    }
}&nbsp;
Any traffic with http header with the above string it need to go to pool B , if not the default pool .
But all the traffic is  just going to the default pool , please help me to get this irule working as expectected.&nbsp;
We are doing ssl offload on f5 and again re-encrypting the data from f5 to the backend servers.&nbsp;

vernonwells · Accepted Answer

No need for any string command. If you don't want to normalize the case, then:
&nbsp;
when HTTP_REQUEST {
    switch -glob [HTTP::uri] {
        ... etc ... 
    }
}

&nbsp;
However, again, you probably want to use HTTP::path, since that's what you're actually matching on. For the case your provide, it would be something like this:
&nbsp;
when HTTP_REQUEST {
    switch -glob [HTTP::path] {
        "*/MembershipEdit" {
            pool poolB
        }
    }
}

&nbsp;
For the example URL you provided, what you're trying to match is essentially "if the Target-Request path ends_with /MembershipEdit, then use poolB". With glob matching:
&nbsp;
    switch [HTTP::path] {
        "/foo" {...}    ; means match if path is exactly /foo
        "*/foo" {...}   ; means match if path ends with /foo
        "/foo/*" {...}  ; means match if path starts with /foo/
        "*/foo/*" {...} ; means match if path contains /foo/
    }

&nbsp;
For what it's worth, I suspect that what you really mean is:
&nbsp;
when HTTP_REQUEST {
    switch -glob [HTTP::path] {
        "*/CustomerDetails" -
        "*/WebofferList" -
        "*/MembershipEdit" {
            pool poolB
        }
    }
}

&nbsp;
What I mean is, I suspect in all cases you are trying to match something at the end of the path, and since you are not normalizing the case (and generally, not normalizing the case of the path is the correct choice), then you must make sure the case matches.

ekaleido · Answer

Are you sure the HTTP::uri is matching? Put in a log command to verify.
inside the HTTP_REQUEST trigger, and above the "switch"
&nbsp;
log local0. "The URI is [HTTP::uri]"

&nbsp;

jinshu · Answer

Please give the exact URI you are trying to redirect.&nbsp;

lmiestc_26212 · Answer

Read this one https://devcentral.f5.com/articles/switch-gone-wild-using-wildcards-with-the-tcl-quotswitchquot-command especially the An example of the "contains" functionality where it selects a pool depending on of the URI and then if no prior match go to the default pool.
So if looking at your irule
when HTTP_REQUEST {
  switch -glob [string tolower [HTTP::uri]] {
    "/customerdetails" -
    "/webofferlist" - 
    "membershipedit/" {
      If URI contains any of the above pool poolB 
    }
    default {
      No prior match so take some default action
      pool name_of_your_default_pool
    }
  }
  Uncomment below if you want to log and see which URI goes to what pool for troubleshooting 
  log local0. "URI: [HTTP::uri] Pool: [LB::server pool]"
}

lmiestc_26212 · Answer

Don't know how to get the edit working in this GUI but the poolB should look like this whith the when HTTP_Reguest first
&nbsp;
     "*/customerdetails*" -
     "*/webofferlist*" -
     "*membershipedit/*"
    {
      If URI contains any of the above
     pool poolB
     }

&nbsp;

please see the https://devcentral.f5.com/s/articles/switch-gone-wild-using-wildcards-with-the-tcl-quotswitchquot-command and you see the proper syntax

vernonwells · Answer

A few other nuances. Firstly, you may wish to use HTTP::path, rather than HTTP::uri. The latter includes Request Parameters (i.e., the stuff starting with the ampersand (&amp;) is a Request Target). If your glob match always ends with an asterisk (*) or you really do want to consider the Request Parameters as part of your match, then HTTP::uri is fine (or, in the latter case, required), but otherwise, HTTP::path is more correct (and, as a bonus, potentially shorter for the string comparison operation).
Secondly, unless you have a case-insensitive filesystem or are mangling the Request Target path (e.g., via Apache mod-rewrite) in a way that treats paths in a case-insensitive matter, you do not need to use string tolower (and you're spending execution cycles without value).
See this recipe for an explanation of these two points:

iRule Recipe 1: Single URL Explicit Redirect

Finally, you do not need (and should not include) the default on the switch. You have already assigned the default pool to the Virtual Server. If the iRule doesn't change the pool selected, then that is the pool that will be used. Again, if you include this default branch, it is costing you execution cycles without value (and may be disruptive if you later change the code or the default pool attached to the Virtual Server).

Forum Discussion

Irule not working as expected

9 Replies

Recent Discussions

Port Group on F5OS network setting

Advise on setting up IRULE

F5 iRule to replace host to path

google-visualization-issues

google autenticator broken barcode

Related Content

F5 SMTP Fast Template - SNAT Not working as expected

F5OS API for downloading files not working as expected

iRULE not working for ipfix log publisher.

iRule for AFM IP Intelligence security policy to work with HTTP XFF (X-Forwarded-For) headers

F5 iRUule not working