Forum Discussion

Chris_Miller's avatar
Chris_Miller
Icon for Altostratus rankAltostratus
Aug 17, 2010

"Event Disable"

I have my LTM checking to see whether a certain cookie exists as part of the HTTP_REQUEST event. If the cookie does exist, I don't need to insert a cookie in the HTTP_RESPONSE event.

 

 

Currently, I'm simply setting a variable to "1" if the cookie's detected and checking the value of the variable during the HTTP_RESPONSE event to see whether it should continue.

 

 

Would it be better to simply use the "Event" command to disable the HTTP_RESPONSE event? So, as part of my "if cookie exists" statement, I'd also be doing "event disable HTTP_RESPONSE"

 

 

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

3 Replies

  • I would say use the event command to disable it in that case for sure. Once you have already done one comparison in the request why do another in the response if you can keep from it? The best thing to do in this case would be to run the timing command on both iRules and then throw some traffic at it to see what is going to be more computationally expensive. http://devcentral.f5.com/wiki/default.aspx/iRules/timing

     

  • I'm still a bit confusd about the command.

    Enables or disables evaluation of the specified iRule event, or all iRule events, on this connection. However, the iRule continues to run.

    Let's say a user establishes a connection in the connection table and does an HTTP GET for 12 images on a page. Does the "event disable HTTP_RESPONSE" command being processed on the first request stop it from happening on every single request for that connection, or is it re-evaluated on each subsequent request?

    I'm just confused on the phrase "on this connection"
  • If you wanted to selectively run HTTP_RESPONSE depending on whether some condition is true in HTTP_REQUEST, you could explicitly disable/enable HTTP_RESPONSE in all cases from HTTP_REQUEST.

     

     

    If you disable HTTP_REQUEST, you do need to worry about that event not being triggered on subsequent requests on the same TCP connection. In general, I don't like disabling events as it would affect all other iRules. It would be a significant pain to be troubleshooting why a new iRule on an existing virtual server doesn't work as expected when another rule on the same virtual server is disabling some of the events. I think it's cleaner to set local variables to track whether iRule code in other events should be evaluated. It's probably slightly less efficient to use this method, but more friendly to yourself and other admins in the future.

     

     

    Aaron