I'm wondering if anyone can shed some light on this error:tmm[1045]: 01220001:3: TCL error: Rule frontend_http - Operation not supported (line 1) invoked from within "HTTP::header insert BIG-IP-PROTOCOL http"rule frontend_http { when HTTP_REQUEST { foreach header {BIG-IP-PROTOCOL BIG-IP-PORT BIG-IP-SERVER-NAME} { set log 0 while { [HTTP::header exists $header] } { HTTP::header remove $header set log 1 } if { $log == 1 } { log local0. "Client-inserted header removed: $header ClientIP: [IP::remote_addr]" } unset log } HTTP::header insert BIG-IP-PROTOCOL http } }Customer is running 9.2.3. Similar issue seen here on 9.1... http://devcentral.f5.com/Default.aspx?tabid=28&view=topic&forumid=5&postid=3513Click here thanks! /deb

Turns out another iRule was running ahead of this one, sometimes resulting in a redirect which causes the (later, unintended) header insertion attempt to fail (see link above). We added the line "event disable all" after the conditional redirect in the preceding rule, and modified the redirect itself to include a Connection: Close header (to prevent subsequent requests on same connection from bypassing the iRule logic):when HTTP_REQUEST { if { condition }{ HTTP::respond 302 Location https://host.company.com[HTTP::uri] Connection Close event disable all } ... }

Just wondering how the LTM behaves when it encounters an errorlike this. If the code had a 'return' instead of an 'event disable', would it send an 'HTTP 302 code' then a RST packet back to the client browser? Or would it just send a RST packet only?

Hi Al - Neither "return" nor "event disable" will cause LTM to send a RST. (The "reject" command may be used to send a RST.) From what I am able to discern, each event runs as a TCL procedure, and "return" terminates the procedure and thus terminates processing for that event until it is triggered again, while "event disable" has a wider effect, preventing the specified event from being triggered at all for the remainder of that connection. (Anyone who knows better, please correct me if I'm wrong about that...) In this case, the preceding rule would have already sent the redirect, and the request is no longer available for header insertion by the second rule, thus the error. If you were seeing RSTs, they may have been generated as a result of the TCL error. HTH /deb

Let me rephrase the question... Does the HTTP::respond (1) send out a packet containing the 302 response immediately or (2) does the response get put in a queue and the actual TCP packets get sent out after all the HTTP_REQUEST events in all the iRules are processed? If it is 2, does an error in an iRule that gets evaluated later cause (1) a RST packet to get added to the queue of outgoing packets or (2) does the outgoing queue get cleared and only a RST packet is sent out? Of course the right thing to do would be to fix the error in the succeeding iRule, but I am just trying to understand the behaviour of the LTM when processing errors in iRules. -Al

Although this Thread is already very old, I want to share my experiences anyway. First of all thank you Deb for the good explanation of this error! We got also the mentioned error message in the logs and after reading your post I understood why. We also have several iRules assigned to the affected VS, one of them doing a redirect. The header insert was in a separate iRule at the end of the iRules list. So I moved this iRule to the first position and now the error doesn't occur anymore. So your "event disable all" is not required for us. Ciao Stefan :)

Error on HTTP::header insert

15 Replies

hooleylist
Cirrostratus
Mar 08, 2012
Hi Stefan,

Sorry, that probably wasn't very clear. Here's how I understand your scenario:

you're currently not using 'event disable all'

one iRule drops a connection using 'drop'

you see an error when calling HTTP::header insert after the prior 'drop' command

I'm saying that's surprising as I expected TMM to handle any subsequent iRule commands after a drop or reject command is used. It would be interesting to see what F5 Support would say for this.

That said, when you're using drop or reject, I think it's safe to call return and then event disable all immediately afterward to prevent any more iRule code from running. You shouldn't see any side effects to this assuming you want to close the connection and stop processing any more iRules.

Aaron
Stefan_Klotz
Cumulonimbus
Mar 08, 2012
Ok Aaron.

But I think the problem in our setup would be, that we have Akamai in place, which is doing some kind of "Oneconnect" towards the BIG-IP. If I would close the TCP-connection, all other sessions within that TCP-connection gets also lost.

As you can see in my other thread, this setup also seems to have some strange side effects when updating iRules.

Do you have any experiences or even tips, when having Akamai in the path?

Ciao Stefan :)
hooleylist
Cirrostratus
Mar 08, 2012
So I didn't have your scenario correct. Are you actually dropping or resetting connections in one of your iRules? I thought that's what you mean when you wrote "...and if not matching, TCP-connection will be dropped".

I replied to your other post as well.

Aaron
Christopher_Ach
Nimbostratus
May 29, 2012
Hi,

We had the same error and this post really helped so thanks everyone.

We had 3 Irules on a VIP and the second iRule has a redirect in it (shown below).

The error was coming from the third iRule. We added "event HTTP_REQUEST disable" into the second iRule (shown below) and it resolved our error.

Here is the iRule

when HTTP_REQUEST {

if { ( ([matchclass [IP::client_addr] equals $::main_page_bypass ])) } {

pool abc

}

elseif { [HTTP::host] eq "xyz.test.com.au"

} {

HTTP::redirect "http://www.abc.com.au/maintenance"

event HTTP_REQUEST disable

}

}

Thanks again

Chris
Darren_Walker_2
Cirrus
Jan 22, 2018
It says in the command documentation that the irule doesn't want to run HTTP::header insert after a HTTP::redirect: https://devcentral.f5.com/wiki/iRules.http__header.ashx

HTTP::header insert

If this command is executed after issuing the HTTP::redirect or HTTP::respond command, the F5 will become confused, generate an "Operation Not Supported" TCL error and reset the connection.