Forum Discussion

Joe_Hsy_45207's avatar
Joe_Hsy_45207
Icon for Nimbostratus rankNimbostratus
Nov 20, 2007

how to detect potential conflict with other iRule?

Hi,

 

 

We have a tool which uses iControl to dynamically add an iRule to a virtual server and it is important to ensure that the iRule we add do not conflict with existing iRules (or other iRules added later).

 

 

Specifically, if there is another iRule which calls HTTP::redirect or HTTP:respond at HTTP_REQUEST event, our iRule must not execute the HTTP_REQUEST block afterwards since our iRule makes a change to the HTTP header (which is not allowed after those two commands). Unfortunately, instead of a simple failure, this break the request and result in error showing at the client's browser.

 

 

We've used the priority to ensure that our HTTP_REQUEST block executes first (e.g. when HTTP_REQUEST priority 0 {...}) and that should work most of the time. However, if another iRule event block also has priority 0, there is still a chance for another iRule to get execute first.

 

 

Is there a way to know if HTTP::redirect or HTTP:Respond has already been called by another iRule, so that our iRule would simple skip execution?

 

 

Thanks!

 

 

//Joe

 

3 Replies

  • There is no built in way to determine this but you can add the logic to your iRules with session variables.

    The following iRule has two HTTP_REQUEST events with different priorities. The lower priority (100) will execute first. In the first iRule, I set a session variable ALREADY_RESPONDED to 1.

    iRule 1:

    when HTTP_REQUEST priority 100 {
      set ALREADY_RESPONDED 1
      HTTP::redirect "http://www.foo.com"
    }

    In the second iRule, check to see if that ALREADY_RESPONDED variable has be set to anything using the "info exists" command. This is basically equivalent to a "is not null" comparison.

    iRule 2:

    when HTTP_REQUEST priority 200 {
      if { ![info exists ALREADY_RESPONDED] } {
         HTTP response not yet sent, continuing with iRule...
      }
    }

    Keep in mind that for keep-alive connections, you may have to "unset" the variable in the last iRule in the chain so that future HTTP requests over the same connection don't inherit the session variable from the previous request.

    -Joe
  • Hi Joe,

     

     

    Thanks for the quick response as always! Indeed given all the iRules for a Virtual Server one can implement such meta-mechanisms for coordination. However, this is not the case for us as we don't have the ability (or should we) to modify other iRules.

     

     

    I think the reason I'm running into corner cases is that we are treating the iRule engine as a open platform for multiple vendors to add value. As such, it is not possible for me (my company) to assume or modify existing iRules or make assumption about other iRules. Our tool must "play nice" (or make the best effort) with other iRules that are already there or may be added.

     

     

    I think there may be a layer of "coordination" features that will need to be added in the iRule (and iControl) platforms to allow multiple vendors solutions to coexist gracefully. I understand this is probably part of a transformational process, but hopefully it is in the future development vision.

     

     

    //Joe
  • Hi Joe,

     

     

    We just ran into this issue again at another customer's site. Is there any plans to add a simple query into whether a there has already been a response executed by another iRule? It seems the information readily availlable to the iRules engine. Should I make a formal request through support?

     

     

    Thanks!

     

     

    //Joe