Forum Discussion
hooleylist
Nov 10, 2006Cirrostratus
Actually, it was pointed out that my last note wasn't correct.
If you use a rule to set the pool to a new value in the HTTP_REQUEST event, it doesn't generate an error as it used to. However, if the request matches an HTTP class with ASM enabled that has a pool configured, that pool will be used for the request, instead of the pool selected in the rule.
If a request matches an HTTP class, the class's pool will be set after the HTTP_REQUEST event and before the HTTP_CLASS_SELECTED event.
So to ensure that changes made in a custom rule to the selected pool aren't overwritten, you would want to select the pool after the HTTP class match has been done (and the corresponding pool is selected) in the HTTP_CLASS_SELECTED event.
If you are using filters on your HTTP classes, and there is a possibility that a request will not match all of the filters of at least one HTTP class, then you would want to add your pool selection logic to the HTTP_CLASS_FAILED event (Click here)
Here is an example rule which shows the how a pool set in HTTP_REQUEST will be overwritten when a request matches an HTTP class:
when HTTP_REQUEST {
set uri [HTTP::uri]
log local0. "uri: $uri"
if { $uri starts_with "/pool" }{
pool http_request_pool
log local0. "Set pool to http_request_pool"
}
elseif { [HTTP::uri] starts_with "/node"}{
node 10.10.31.14 80
log local0. "Set node to 10.10.31.14 80"
}
else {
log local0. "No match in HTTP_REQUEST, using default pool"
}
}
when HTTP_CLASS_SELECTED {
if { $uri starts_with "/selected/pool" }{
pool http_class_selected_pool
log local0. "Set pool to http_class_selected_pool"
}
elseif { [HTTP::uri] starts_with "/selected/node"}{
node 10.10.31.15 80
log local0. "Set node to 10.10.31.15 80"
}
else {
log local0. "No match in HTTP_CLASS_SELECTED, using default pool"
}
}
And here is a sample VIP and a catch-all HTTP class which reference the rule:
virtual asm_http_vip {
destination 172.24.59.174:http
snat automap
ip protocol tcp
profile http tcp
rule select_pool_node_rule
httpclass asm_httpclass
}
profile httpclass asm_httpclass {
defaults from httpclass
hosts none
paths none
headers none
cookies none
pool httpclass_pool
asm enable
}
Requests that match the HTTP_REQUEST criteria for going to the pool or node set will actually be routed to the pool configured on the HTTP class.
Requests that match the HTTP_CLASS_SELECTED criteria for going to the pool or node will be routed to that pool or node because the change is made after the pool in the HTTP class was selected.
And again, if there are filters on the HTTP class and it's possible that a request would not match the filters, you would want to add additional logic in the HTTP_CLASS_FAILED event to ensure the request is handled as you want. Else, the behavior would be to use the default pool on the VIP if there is one (and therefore bypassing ASM).
Aaron