Forum Discussion
jeff_mccombs_47
Nimbostratus
Jun 15, 2009Any problems with this?
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] > 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
Cirrostratus
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.
Recent Discussions
Related Content
DevCentral Quicklinks
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com
Discover DevCentral Connects