Forum Discussion
Zev
Altostratus
AltostratusiRules fail in v14.1.2.3
I recently upgraded from v12.x to v14.1.2.3 and simple redirect/rewrite iRules seem to fail. At first I removed the iRule, deleted it and just recreated it and this worked for a bit (2nd rule below)! However, it suddenly fails and I cannot tell why this would happen. I have seen a number of similar threads but nothing really answers the issues.
I have one irule that contains:
when HTTP_REQUEST {
switch [string tolower [HTTP::host]] {
"support1.xyz.com" {
# port 7080
log local0.
pool SupportPool
}
"support2.xyz.com" {
# port 7080
log local0.
pool SupportPool
}
}
}
And another that contains:
when HTTP_REQUEST {
switch [string tolower [HTTP::host]] {
"support2.xyz.com" {
if { [HTTP::uri] equals "/" } { HTTP::redirect "/portal/ss/?guest=0"}
}
"support1.xyz.com" {
switch -glob [string tolower [HTTP::uri]] {
"/" { HTTP::redirect "/portal/ss" }
"/support" { HTTP::redirect "/portal" }
"/downloads" { HTTP::redirect "https://ftpdl.xyz.com" }
}
}
}
}
I've read maybe these are now in conflict with how v14.x looks at iRules? Regardless, this worked flawlessly up until now. I cannot make sense of it as the syntax is correct! Now if any of the URIs are typed it returns a PR_CONNECT_RESET_ERROR error in browser as if the pool or iRule doesn't exist. Is there a new way to express this or new syntax?
Simon_BlakelyEmployee
In version 14.1.0, once you have executed a HTTP::redirect/HTTP::respond command, any further reference to the contents of HTTP:: functions (uri, host, path etc) cause an error.
You can use HTTP::has_responded to determine if a previous irule has already executed HTTP::redirect/HTTP::respond.
K23237429: TCL error: ERR_NOT_SUPPORTED after upgrade to version 14.1.0 or later
ZevSB,
Thanks, this is the most direct answer I have found. I am not exactly sure how I would integrate HTTP::has_responded in to this 2nd iRule as I need the rewrites to function/take precedence. It seems the order is different as well. I was just beginning to understand iRules in v12 now I am a little lost again.
- Simon_Blakely
First - always use priority statements to control event execution order if you are using multiple irules with the same event.
Second, at the start of the earliest executing event, set variables that contain the things you might need in later irule events (HTTP::host, HTTP::uri, HTTP::path, etc). Then refer to the variables rather than the HTTP:: functions.
Use the following code fragment after a HTTP::redirect/HTTP::respond
... HTTP::redirect "<location>" event disable return ...
VBNimbostratus
Hi Zev Hi Simon,
We have the same issue with a very large and old irule using a switch.
We tried and tried but do not seem to find the correct syntax to make the irule work.
Does one if you have an example for using the HTTP::has_responded function within a switch?
(and yes we are already planning a move to using LTM policies but with multiple irules on a VS its not that easy)
- Simon_Blakely
Use the following patterns from K23237429 everywhere:
when HTTP_REQUEST { if {[HTTP::has_responded]}{return} ... and ... HTTP::redirect "<location>" event disable return ... - Zev
Yes, Simon is correct here and I found that the 'event disable' is a critical piece! This is the only helpful answer. Literally everyone will advise to use HTTP::has_responded, even F5 LTM support and Reddit, but you must complete the pattern with event disable. Follow this syntax; I've had no more issue.