Error on HTTP::header insert

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 :)

 

Hi Stefan,

 

 

Thanks for the info. You could also use a local variable to track whether you've done a redirect and then read that in subsequent iRules to avoid trying to do a header insert if you're redirecting (or trying to send a second redirect). I try to stay away from event all disable as it could break other iRule functionality.

 

 

Another option is to use logic like this to detect a prior redirect:

 

 

http://devcentral.f5.com/wiki/default.aspx/iRules/detect_prior_http_redirect_or_respond.html

 

 

Aaron

Keep in mind that while cool and a fun trick, using the catch statements like shown in Aaron's CodeShare example add overhead. It's an outstanding tool to use where you need to, but I wouldn't recommend using it as a standard practice unless you're sure you'll be encountering these situations often.

 

 

Colin

Hello again,

 

same issue, but different root cause.

 

I noticed, that we still sometimes get this TCL-error in the logs.

 

As we are using a "default" iRule, which is in place on several VS, I checked all of them to verify if there is maybe another iRule in place, which performs a redirect.

 

I didn't found such an iRule, but other iRules doing an "IP whitelisting" and if not matching, TCP-connection will be dropped. I guess the behavior is similar to a redirect. The TCP-connection isn't available anymore for HTTP header insertation.

 

I will try to move the HTTP header insertation iRule on the very top of all VS.

 

 

Ciao Stefan :)

 

Hi Stefan,

 

 

If the connection is being dropped in a rule and you're getting runtime errors from a later rule you could safely call event all disable in that first rule which is dropping the connection.

 

 

That said, I'm surprised you'd get a runtime error in this situation. Have you or can you open a case with F5 Support on this? If so, can you reply with the case number?

 

 

Thanks, Aaron

Hi Aaron,

 

I guess you misunderstand me. I don't use the "event disable all" command.

 

I only want to share my experiences that dropping or rejecting a TCP-connection will also result in this TCL-error, when trying to insert HTTP-headers in any later iRules on the same VS.

 

As I mentioned, I will move our HTTP-header insert iRule at the very beginning of the VS and I expect no further issues. Regarding the "event disable all", I'm little bit afraid of using it, because there might be any negative influences for other functionalities especially when it's a default iRule, which is in place on several VS (if I remember correctly I tried this in the past and had some strange behaviors).

 

 

Ciao Stefan :)