Forum Discussion

ScreenScape_Jim's avatar
ScreenScape_Jim
Icon for Nimbostratus rankNimbostratus
May 02, 2012

Need workaround for 10.x Caching issue with HTTP::uri updates

We have developed an irule that was developed on 9.4.8 to use with our marketing web site where we parse the URI and decide where to send the client's request. Some are redirects which work fine and the pool assignments work fine as well.

 

 

The final 3 in the irule involve updating the HTTP::uri and connecting to the pool web-pool with the correct formatted string that the php code is expecting. Currently we are experiencing the cached value of HTTP::uri being sent though to the web-pool.

 

 

We are in the process of moving to 10.2.4 and have this one last irule that needs to be adjusted for the caching issues on the 10.X platform.

 

 

 

Any suggestion on how I should rewrite or restructure this irule?

 

 

 

when HTTP_REQUEST {

 

if { [HTTP::host] eq "hostname" } {

 

 

 

check for global redirects first

 

set gohere [class match -value [string tolower [HTTP::uri]] equals global_redirect_urls]

 

if { $gohere ne "" } {

 

HTTP::redirect $gohere

 

}

 

unset gohere

 

 

set path [string tolower [HTTP::path]]

 

if {$path ends_with "/" and $path ne "/"} {

 

set path [string range $path 0 end-1]

 

}

 

 

 

set query [HTTP::query]

 

if {$path ends_with "/" and $query contains "member"} {

 

HTTP::redirect "http://[HTTP::host]/explore/?$query"

 

}

 

 

 

switch -glob $path {

 

"/app*" -

 

"/account*" -

 

"/groupmanager*" -

 

"/login*" -

 

"/signup*"

 

{

 

send to application servers with same path

 

HTTP::redirect "http://manage.[HTTP::host]$path?$query"

 

}

 

 

 

"/press*"

 

{

 

cleanup the press URI and send to wordpress server

 

HTTP::redirect "http://press.hostname.net/press/[string range [HTTP::uri] 7 end]"

 

}

 

 

 

"/blog*"

 

{

 

cleanup the press URI and send to wordpress server

 

HTTP::redirect "http://blog.hostname.net/[string range [HTTP::uri] 5 end]"

 

}

 

 

 

"/directory*"

 

{

 

pool app-pool

 

}

 

"/favicon.ico" -

 

"/sitemap.xml" -

 

"/index.php" -

 

"/"

 

{

 

pool web-pool

 

}

 

 

 

"/search*"

 

{

 

apply filter for search page and redirect with query string for Google CSE

 

HTTP::uri "/index.php?page=search&$query"

 

}

 

 

 

"/forms*"

 

{

 

parse for second level and send as form name

 

set formname [string range [URI::path [HTTP::uri] 2 2] 0 end-1]

 

HTTP::uri "/index.php?page=forms&form=$formname"

 

pool web-pool

 

unset formname

 

}

 

 

 

default {

 

apply filter for page name and redirect to handle pages

 

set tempuri "/index.php?page=$path&$query"

 

log local0. "URI after: $tempuri"

 

HTTP::uri $tempuri

 

pool web-pool

 

}

 

}

 

unset path

 

}

 

}

 

 

 

application delivery
dev
devops
iRules
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    May 02, 2012
    Hi Jim,

    The caching is just within the same iRule event and priority. The actual URI sent in the request to the pool is updated. If you need to see the change within the iRule you can either use an intermediate variable like you've done in the default switch case, or add a second HTTP_REQUEST event with a later (higher number) priority: 

    
 https://devcentral.f5.com/wiki/iRules.priority.ashx
when HTTP_REQUEST priority 501 {
   log local0. "Updated URI: [HTTP::uri]"
}

    Aaron
  • ScreenScape_Jim's avatar
    ScreenScape_Jim
    Icon for Nimbostratus rankNimbostratus
    May 03, 2012
    Thanks for the note today but the irule for the last 2 and default switch case all pass through the original URI unchanged. I verified this by reviewing the apache web server access logs. The temporary variables all show OK and updated as noted in other forum posts on the topic.

     

     

    Should I be writing the these last 2 and the default switch case different for the HTTP::uri update?

     

     

    Is there any other way to validate or do a workaround for this issue?

     

     

    Jim
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    May 03, 2012
    I can't see how the URI in the proxied request wouldn't be updated if you're calling HTTP::uri to update it.

     

     

    Can you edit your post above and add [ code ] [/ code ] blocks (without spaces around "code") to preserve the spacing in the iRule? Can you also add log commands to the switch cases you think aren't updating the URI to ensure that code is being hit? You can also add the HTTP_REQUEST priority 501 event to log the current URI.

     

     

    Thanks, Aaron
  • ScreenScape_Jim's avatar
    ScreenScape_Jim
    Icon for Nimbostratus rankNimbostratus
    May 04, 2012
    In troubleshooting this further today with Tech Support (crunch time deadline was coming too close), we isolated the irule on its own with only one virtual server in http only mode and magically the irule worked. We identified that the order that I had multiple irules applied on the virtual server was the issue. I just moved it to the top of the list and issue was resolved.

     

     

    The F5 engineer sent me this summary : On way you can think of it is that when multiple iRules are associated to a virtual server and the event priority is the same (default priority is 500 I believe) then the event blocks of the separate irules will be merged into one event block in the order they are attached to the virtual server. Another method by which you might have solved this would have been to give the event block containing the HTTP::uri code a higher priority so it would run before the lower priority event blocks of the same event. Please see: https://devcentral.f5.com/wiki/iRules.priority.ashx.

     

     

    Cheers!
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    May 04, 2012
    That makes sense. Just one minor correction to that: the higher the priority number, the later the event will run. So a priority 1 rule will run first, then a priority 500 rule followed last by a priority 1000 rule.

     

     

    Aaron