cancel
Showing results for 
Search instead for 
Did you mean: 
Login & Join the DevCentral Connects Group to watch the Recorded LiveStream (May 12) on Basic iControl Security - show notes included.

iRules fail in v14.1.2.3

Zev
Altostratus
Altostratus

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?

 

 

6 REPLIES 6

Simon_Blakely
F5 Employee
F5 Employee

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

SB,

 

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.

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 ...

 

VB
Nimbostratus
Nimbostratus

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)

 

Use the following patterns from K23237429 everywhere:

when HTTP_REQUEST { if {[HTTP::has_responded]}{return} ... and ... HTTP::redirect "<location>" event disable return ...

 

Zev
Altostratus
Altostratus

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.