Forum Discussion
Multiple redirect/respond invocations not allowed
Haveing a problem with a iRule I created. everytime it runs we get the following error message. TCL error: Rule jdhealth_http - Operation not supported. Multiple redirect/respond invocations not allowed (line 8) invoked from within "redirect to "https://[HTTP::host][HTTP::uri]" "
When I log the url/uri this is what I get www.johndeerehealth.com/. Below is the rule any help would be great.
when HTTP_REQUEST {
if { [HTTP::uri] == "/provider" or
[HTTP::uri] == "/provider/" or
[HTTP::uri] == "/Provider" or
[HTTP::uri] == "/Provider/" } {
use pool johndeerehealth
} else {
redirect to "https://[HTTP::host][HTTP::uri]" }
}
12 Replies
- This look to be a bug, I failover to the standby unit and the tcl error went away and the rule works fine. I am going to open a support case.
- I've tested this exact rule on a v9.0.5 machine and it loaded without any errors.
Have you seen this error occur on multiple machines, or could it be a problem with the machine you first loaded the rule on, not the rule itself?
-Colin - It looks like the system once I fail over to the standby the rule work fine. Once I failed back the old active unit the rule starts failing again. I have an open case with support.
- You normally get that error if you call ‘HTTP::redirect’ more than once from a single request/response. Can you add some log information to get a little bit more information on what’s going on?
- The redirect is only being called once. It has to be a problem with our unit, once we failed over to our standby the same rule starts to work no errors. If I fail back to the other unit the rule breaks again. After I sent the message and open the support case people have been stoping by and reporting that the BigIp has been doing some wierd things all morning, so the more I look at it there is something going on with our other unit.
- Just to let you guys know once I did a bigstart restart on the failing box the rule started working again.
- Sheesh, go on vacation and look what happens...
Darn, I was too late, I was hoping to get a coredump of that tmm so we could analyze what was broken. Our suspicion is that somehow two instances of your rule got onto that virtual. A coredump would have helped determine why and how that might have happened. If it does happen again, please contact support and tell them that DevCentral instructed you to take a coredump.
Thanks and I will spend a little time looking closely at that code again. - Support is telling me that 9.1 will most likly fix my problem is this true? We were planing on doing the upgrade anyway, just do not what to have to upgrade then throw a hotfix on a few weeks latter. Thanks
- I can't confirm that it will. We have only seen signs of a bug like this once before (there are often iRule mistakes that lead to the same error) and we were not able to pin it down specifically. We have made quite a few fixes in 9.1, so it is possible that this bug was a side effect of something we have fixed. I would definitely still recommend upgrading to 9.1.
- Good new and bad news out devl unit started haveing the same problem I will get you your core bad new is these are 9.1 units. Failed over the units and the rules started working, just like our production units.
