Forum Discussion
parsing a datagroup/class
Hi all,
I have this situation. Our iRule for our main website now has a lot of redirects which are based on the URI specified. There are now getting to be quite a few of these and for various reasons I won't go into it is getting to be a bit of a pain to maintain these in iRules. I briefy looked at using HTTP Classes and although they addressed some of my issues, for some reason I could not get case insensative matches to work reliably. What I am now thinking of doing is using a datagroup/class where the string name will be the URI to match on and the value will be the URI to redirect to.
eg.
StringName Value
/contactus /public/contact-us
/help /public/help
So the iRule logic would be something like
if the uri equals the value of the first element redirect to 2nd element
Obviously, it would need to repeat this until it exhausts all of the entries in the datagroup.
I feel this will be a much simpler way to manage these redirects. So, can anyone give me any pointers on how I would go about coding this in a iRule? I'm currently going over the class statement and I'll see if I can nut it out for myself, but I am not adverse to any pointers :)
tia
Craig
- hooleylistCirrostratusHi Craig,
when HTTP_REQUEST { Check the requested path, set to lower case to see if it exists in the uri_map_dg datagroup If there is a match, save the corresponding value set new_path [class match -value -- [string tolower [HTTP::path]] equals uri_map_dg] If there was a matching path, update the requested path if {$new_path ne ""}{ HTTP::path $new_path } }
when HTTP_REQUEST { Check the requested path, set to lower case to see if it exists in the uri_map_dg datagroup If there is a match, save the corresponding name and value to do the update set old_and_new_path [class match -element -- [string tolower [HTTP::path]] starts_with uri_map_dg] If there was a matching path, update the requested path Use string map to replace the old with the new in the path if {$new_path ne ""}{ HTTP::path [string map $old_and_new_path [HTTP::path]] } }
- CraigM_17826AltocumulusHi Hollio,
- Colin_Walker_12Historic F5 AccountThere are always lots of ways to do things when programming, and adding a layer of networking options to the mix doesn't narrow your choices much. ;)
- hooleylistCirrostratusUsing class match should return the longest (most accurate) match and be more efficient than manually looping through the data group contents entry by entry and tracking which match is the longest.
- CraigM_17826AltocumulusThanks for the comments everyone. I'll give Aaron's code a try and see how it goes.
- CraigM_17826AltocumulusHi Arron,
- nitassEmployeei see Aaron's irule already use string tolower, so it should work even user uses mix of case, shouldn't it?
- nitassEmployee
[root@ve1023:Active] config b virtual bar list virtual bar { destination 172.28.19.79:80 ip protocol 6 rules myrule profiles { http {} tcp {} } } [root@ve1023:Active] config b rule myrule list rule myrule { when HTTP_REQUEST { set new_uri [class match -value -- [string tolower [HTTP::uri]] equals uri_map_dg] if {$new_uri ne ""}{ HTTP::redirect http://[HTTP::host]$new_uri } } } [root@ve1023:Active] config b class uri_map_dg list class uri_map_dg { { "/contactus" { "/public/contact-us" } "/help" { "/public/help" } } } [root@ve1023:Active] config curl -I http://172.28.19.79/contactus HTTP/1.0 302 Found Location: http://172.28.19.79/public/contact-us Server: BigIP Connection: Keep-Alive Content-Length: 0 [root@ve1023:Active] config curl -I http://172.28.19.79/contactUS HTTP/1.0 302 Found Location: http://172.28.19.79/public/contact-us Server: BigIP Connection: Keep-Alive Content-Length: 0 [root@ve1023:Active] config curl -I http://172.28.19.79/help HTTP/1.0 302 Found Location: http://172.28.19.79/public/help Server: BigIP Connection: Keep-Alive Content-Length: 0 [root@ve1023:Active] config curl -I http://172.28.19.79/Help HTTP/1.0 302 Found Location: http://172.28.19.79/public/help Server: BigIP Connection: Keep-Alive Content-Length: 0
- CraigM_17826Altocumulus
Hi Nitass,
the case insensative match works fine on the [HTTP::path] test, but if the datagroup element name and value is enetered in uppercase then the case statement fails...or at least that is what I think I am seeing , because the lowecase PATH value will not match the uppercase values in the datagroup. Although I can document the need for the use of lowercase characters in the datagroup, if someone ignores this, then the match will fail, so I was looking at ways to overcome this. It seemed (at first glance) that this would be trivial but I can't get it to work.
- hooleylistCirrostratusHi Craig,
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com