Any problems with this?

Question

So I've been playing around with chaining rules together. I've got some basic rules that I typically want applied to each of my VSs, and then there are some more "custom" rules (pool selections, etc.).   
 I got to thinking about this a bit, and I came up with a way, I think, to make it so that these generic rules can be configured on a per-VS basis for things like debug or other log messages, or even disabling a rule all together using classes.   
 so lets say I have a VS called "production.myapp.com". I have some generic rules in place that strip out unwanted HTTP methods, enable cookie encryption, etc. If I did something like:   
    
 class productionMyapp_config {   
      "http_method_check_enabled 1"   
      "http_method_check_debug 1"   
      "cookie_encryption_enabled 1"   
      "cookie_encryption_debug 1"   
 }   
    
 then applied 3 rules to the VS, the two "generic" rules for cookie encryption and method checks, and then the custom rule..    
    
 virtual production.myapp.com {   
 rules   
      http_method_check   
      cookie_encryption   
      productionMyapp    
 }   
    
 And for the rules:   
    
  method check rule:   
 rule http_method_check {   
      when HTTP_REQUEST priority 100 {   
           if { $http_method_check_enabled } {   
                 blah blah blah, reject all HTTP requests    
                 that are not GET/POST/HEAD   
           }   
      }   
 }   
  
  cookie rule   
 rule cookie_encryption {   
      when HTTP_REQUEST priority 400 {   
           if { $http_encryption_enabled } {   
                 blah blah blah, setup AES keys, etc.    
           }   
      }   
 }   
  
  vs rule   
 rule prodctionMyApp {   
      when CLIENT_ACCEPTED priority 100 {   
           foreach configOption $::productionMyapp_config {   
                 check to make sure we have enuff arguments. 
                 If we do, go ahead and "set" the variable and it's value.   
                if { [llength $configOption] &gt; 1 } {   
                     set [lindex $configOption 0] [lrange $configOption 1 end]   
                }   
           }   
      }   
  
      when HTTP_REQUEST priority 500 {   
            Do your magic here.   
      }   
 }

That should work out OK (i think). But I'm wondering if this is really a good idea or not? Aside from having to loop through whatever settings are in the class on each TCP connection made to the VS, which could - depending on complexity - slow things down quite a bit, are there any other drawbacks? Is there perhaps a better location to place the configuration settings? -- I'm trying to avoid RULE_INIT, since I don't want to have to 'resave' the rule to make setting updates..    
 this make sense to anyone?

hoolio · Answer

That looks good for handling the config for multiple iRules in a central location.  I think the overhead of parsing the array on each request isn't worth saving the effort of resaving the iRule with the config being parsed in RULE_INIT. 
&nbsp;  
&nbsp; Aaron

Forum Discussion

Recent Discussions