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