For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

detect prior http redirect or respond

Problem this snippet solves:

Summary: Detect a prior HTTP redirect or response to avoid a runtime TCL error

iRule Methodology:

This iRule detects when this or a prior iRule has issued an HTTP redirect (using HTTP::redirect) or HTTP response (using HTTP::respond) to avoid a runtime TCL error:

01220001:3: TCL error: Rule eschool_http_redirect - Operation not supported. 
Multiple redirect/respond invocations not allowed (line 7) invoked from within "HTTP::redirect https://[HTTP::host][HTTP::uri] " 

Code :

# Example 1 - Detect prior HTTP::redirect or HTTP::respond

when HTTP_REQUEST priority 999 {
 
   # Ensure this event runs after any iRules which should take precedence over this one
   # Check if an HTTP redirect/response has been triggered already.
   if { [catch {HTTP::payload replace 0 0 {}}] } {
      set already_responded 1
   } else {
      set already_responded 0
   }
 
   if {$already_responded == 0}{
 
      # Do something like select a pool or redirect the client
   }
}


# Example 2 - Detect prior HTTP::redirect or HTTP::respond or pool change

when CLIENT_ACCEPTED priority 1 {
 
   # Ensure this event runs first to save the VS's default pool name
   set default_pool [LB::server pool]
}
when HTTP_REQUEST priority 999 {
 
   # Ensure this event runs after any iRules which should take precedence over this one
   # Check if the currently selected pool has changed or an HTTP redirect/response has been triggered already.
   if { ([LB::server pool] ne $default_pool) or [catch {HTTP::payload replace 0 0 {}}] } {
      set already_responded 1
   } else {
      set already_responded 0
   }
 
   if {$already_responded == 0}{
 
      # Do something like select a pool or redirect the client
   }
}
Published Mar 17, 2015
Version 1.0

1 Comment

  • I'm trying to understand how this works. When a subsequent redirect is issued after the first redirect is that when the error occurs? Or does the error happen at the end? I use multiple iRules in a modular fashion and I have to put code in the top of every iRule to detect if a redirect or respond has already happened. The issue is that every time we do a respond or redirect, we also have to remember to set a variable called gRespondOrRedirect. Maybe this is a different case, but I do not see how this would prevent a downstream iRule from doing the second respond or redirect and causing the TCL error. I still believe the core issue is that all iRule processing for a given event does not stop when one does a respond or redirect. A HTTP::respond 302 noserver -abort Location "..." would be helpful.