Forum Discussion

BaltoStar_12467's avatar
Mar 12, 2015

BIG-IP : expected behavior of redirects in irule stack

F5 BIG-IP Virtual Edition v11.4.1 (Build 635.0) LTM on ESXi

My virtual-server has an iRule stack. In the top-level iRule ( highest-priority, lowest numerical priority), under certain conditions I set the destination pool and perform redirects ( 301 302 ) :

"mysite.com" {
    pool mysite.com-pool-01
}
"mysite.co.uk" {
    HTTP::respond 301 Location "http://www.mysite.co.uk[HTTP::uri]"
}
"www.mysite.com.mx" {
    HTTP::redirect "http://www.mysite.com/default.aspx?c=6"
}

I know that destination pool can be reset in subsequent iRules -- and so final route might be to a different pool.

But what is expected behavior with respect to redirects ? Once

HTTP::redirect
or
HTTP::respond
is issued, is this route immediately acted upon ? ( i.e. no further iRule processing occurs ) Or is it possible that subsequent iRule could effect a different response ?

3 Replies

  • nathe's avatar
    nathe
    Icon for Cirrocumulus rankCirrocumulus

    HTTP::redirect and HTTP::respond are commands so the irule will issue that command and the browser, in this case, will perform the command. So, because they are client side cmds, in effect, the subsequent cmds won't be actioned, unless the redirect points back to the same VIP and irule.

     

    Hope this is true,

     

    N

     

  • Once HTTP::redirect or HTTP::respond is issued, is this route immediately acted upon ? ( i.e. no further iRule processing occurs )

     

    no, further irule will still be triggered.

     

    Or is it possible that subsequent iRule could effect a different response ?

     

    yes

     

    generally what people do is either to disable further event (event disable command) or perform action on the last (lowest priority) irule (set variable in higher priority irule but execute command in the lowest one).

     

    event

     

    https://devcentral.f5.com/wiki/iRules.event.ashx

     

  • Arie's avatar
    Arie
    Icon for Altostratus rankAltostratus

    If a single criterion applies to multiple responses (i.e. HTTP::redirect and HTTP::respond) you will encounter an exception. In browsers this is usually displayed as "connection reset" and in the error logs you'll see entries for "multiple responses".

    In addition to

    event disable
    (which I do not prefer because it universally halts all further processing) and executing the actual command last there is a third option: using a semaphore.