Forum Discussion
ScreenScape_Jim
Nimbostratus
NimbostratusNeed 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
}
}
hoolioCirrostratus
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_JimThanks 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- hoolioI 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_JimIn 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! - hoolioThat 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