Forum Discussion

Deb_Allen_18's avatar
Deb_Allen_18
Historic F5 Account
May 18, 2005

matchclass syntax / allowed operators

is this valid syntax for matchclass?

[matchclass $inbound_uri starts_with $::uri_redirects]

I'm trying to redirect based on a variable length leading directory in the URI string.

Here's the relevant parts of the rule with the ultimate intention of redirecting all request for /ambulance* to the corresponding URI built from the 2nd field in the class:

 
 when HTTP_REQUEST { 
    set inbound_uri [string tolower [HTTP::uri]] 
    if { [matchclass $inbound_uri starts_with $::uri_redirects] } { 
       set inbound_pid [getfield [findclass [substr $inbound_uri 1 /] $::uri_redirects] " " 2] 
       HTTP::redirect "http://host.domain.com/dir1/dir2/index.jsp?id=a0a0164000000ff706071f000000006&pid=${inbound_pid}&ptype=list" 
    } 
 } 
 

Class uri_redirects contains members like:

"/ambulance "

thanks for any insight regarding matchclass syntax and allowed operators, or just a better way to build the mousetrap...

cheers!

/deb
  • Colin_Walker_12's avatar
    Colin_Walker_12
    Historic F5 Account
    Deb,

     

     

    Yes, the "starts_with" operator is legitimate in conjunction with "matchclass". This should work the way you are looking for, much like the "contains" operator. The difference being that it will attempt to match from the beginning of the uri when comparing it to each member of the class. "contains" would match the member string anywhere in the uri.

     

     

    I.E, assuming the uri_redirects class contains a member defined as "/ambulance":

     

     

    when HTTP_REQUEST {

     

    set inbound_uri [string tolower [HTTP::uri]]

     

    [matchclass $inbound_uri starts_with $::uri_redirects]

     

     

    would match

     

     

    http:///ambulance/

     

     

    but not

     

     

    http:////ambulance/

     

     

    Using the same rule with the "contains" operator would match both, which can cause unwanted behavior in some cases.

     

     

    Hopefully this answers your question.

     

     

    -CW
  • unRuleY_95363's avatar
    unRuleY_95363
    Historic F5 Account
    BTW, as of 9.0.4 the following line:

    set inbound_pid [getfield [findclass [substr $inbound_uri 1 /] $::uri_redirects] " " 2]

    can be condensed to:

    set inbound_pid [findclass [substr $inbound_uri 1 /] $::uri_redirects " "]

    This is because the findclass command can take an optional 3rd argument that is used to split the entry and return the portion following the split string.
  • Deb_Allen_18's avatar
    Deb_Allen_18
    Historic F5 Account
    excellent, thank you both!

     

     

    Is the matchclass command documented anywhere?

     

     

    There seems to be some disparity of syntax in the examples in this forum, esp obvious in use of comparison operators (i.e. "==" "eq" "equals" all seem to be valid equality operators), which leaves me wondering if there's a preferred approach, or if the operator is dependent on the data type or something else I'm missing???

     

     

    thanks again

     

    /deb
  • unRuleY_95363's avatar
    unRuleY_95363
    Historic F5 Account
    The main difference for the equality operators is between "==" and "eq". "equals" is merely an F5 synonym for "eq". The difference is that Tcl treats "eq" as a string comparison only. So, the operands of the operator are always converted to string form and then compared. The "==" operator is slightly different in that the operands are first tested to see if they are of the same type and compared in their native type (for example, two integers would be compared as integers instead of converted to strings and then compared). For the most part, the result would likely be the same using either operator, however using the "eq" operator on non-string operands could have strange side effect and/or an impact on performance.