Forum Discussion
CirrusMultiple redirect/respond invocations not allowed
Hi,
Im trying to rebuild our old desing from 11.2 in an 11.5 environment. But Here I have a problem with multiple redirects.So, I have a VS with oneconnect, a default pool, a LTMPolicy and an irule.
In the Irule a have a IP filter and repond with an error page, if it hit.
In the LTMPolicy I have 3 rules. 2 for selecting the correct ASM policy depending on the uri and a default rule for a redirect to a URL, if the rules 1 and 2 not hit. And here is the problem.
If I remove the redirect from the default rule, everything is ok. If not, I get the error message Operation not supported. Multiple redirect/respond invocations not allowed (line 1) invoked from within "HTTP::respond 503 content {...
I want this default redirect, if some request an not existing application. My simple irule:
when HTTP_REQUEST {
if { [class match [IP::client_addr] equals IPGroup-public_network] } {
hit
HTTP::respond 503 content {
...
} noserver Connection Close
event disable
return
}
}
Is the only way a additional uri check in the irule? This would be strange, because I have to do this twice.
3 Replies
- Stefan_Klotz
Cumulonimbus
Hi Torti,
that's one of the potential issues if you spread your "advanced" logic across several iRules.
It seems the problem only occurs if the IP-filter iRule AND the default redirect iRule are executed at the same time. So either you have to put all the logic (or at least the redirect/respond logic) into ONE iRule and separate it with different if-statements or you have to set some kind of flag in your first IP-filter iRule, so that your default redirect iRule "knows" that for this kind of request it should not respond with the 503 code.
Ciao Stefan :)
- Kevin_Stewart
Employee
The issue is that you're potentially attempting to invoke multiple redirects in a single flow. I'm going to use my "bucket" analogy here. iRules don't really follow a procedural top-to-bottom code flow, but rather are dependent on network flow. So think of an HTTP_REQUEST event as a bucket. The event is triggered when all of the request headers have been received and are now in the bucket. Within the span of that event, you have the option to manipulate the values in this bucket as desired, and at the end of the event the data is "normalized" and dumped onto the wire. If at the end of the event, you've created multiple redirect invocations, that's a problem, because it can't be rationalized.
So in a round-about way, through an admittedly terrible analogy, the point is that you have to make sure that only one redirect is handled within the event. And you have a few options:
Combine everything into one iRule and use if/switch conditioning to ensure that only one redirect path is taken per request.
Set a variable in the "higher priority" rule and check for it in the lower priority rule(s):
if { not ( [info exists stop] ) } { ... continue processing logic with additional redirects }Admittedly a bit kludgy, but should work.
Tortithx, for reply.
Now, I did try the same construct in our new (fresh) 11.5 environment. Here, I don't get this error :-D So, there seems to be a problem in the old environment, which comes frome 10.x originally. So, I will reset this system.
Now, I did test with 2 irules, instead of a Rule (LTM policy) and an irule. Here I get the multiple redirect error again. To set a variable would be a possible way, but then I can integrate everything in 1 irule, too.
everything in one irule is working fine.
