pool set in irule overidden by httpclass

My initial thought was to use the Return command, but that won't work.

 

 

 

Note that return does not:

 

 

1. cause an exit from the iRule altogether;

 

2. prevent the same event from firing in another iRule; or

 

3. prevent the same event with a higher priority value from firing in the same iRule.

 

 

To prevent further processing of an event in the current rule or other rules for the current TCP connection, you can use 'event EVENT_NAME disable'.

 

 

 

Wiki for Return Command: http://devcentral.f5.com/wiki/default.aspx/iRules/return.html

 

 

I don't currently have any iRules that I'm working on where I would use it, so I'd be very interested in seeing what you come up with if this works for you.

 

 

Wiki for Event Command: http://devcentral.f5.com/wiki/default.aspx/iRules/event.html

You could use the HTTP::class disable command to prevent HTTP class matching from happening, and event disable to prevent any further iRules from firing; you could also specify the HTTP_REQUEST event with that last command to prevent only that event from proceeding further. Note that both of those commands operate on a per-connection basis, not per-request. If you wanted the next HTTP request on the same connection to be treated normally, then you'd need to reenable both of those later in the transaction, perhaps in HTTP_RESPONSE.

You could also override the pool selection done by an HTTP class if you set the pool in the HTTP_CLASS_SELECTED event.

 

 

If there isn't a class matched and no pool has already been specified either in an iRule or on the VIP, you could set one in the HTTP_CLASS_FAILED event which is triggered when no class match is made on a VIP with one or more HTTP classes added.

 

 

http://devcentral.f5.com/wiki/default.aspx/iRules/http_class_selected

 

http://devcentral.f5.com/wiki/default.aspx/iRules/http_class_failed

 

 

Aaron

The problem he's running into though is that the class IS catching the URL and forwarding incorrectly. I think spark's idea of shutting off class matching for this request and then re-enabling as necessary is the best approach.

 

 

Just be sure you turn class matching back on in the response if you want this connection to behave normally after the initial pool selection.

 

 

Colin