Forum Discussion
hoolio
Cirrostratus
CirrostratusUsing PROFILE::httpclass to get HTTP class configuration info
Hello,
I'm trying to understand how to access HTTP class characteristics and then use a rule to select between a set of HTTP classes based on the filters of the classes.
I found in the profile_base.conf that you can determine whether App Security is enabled on an HTTP class in the context of HTTP_CLASS_SELECTED, using:
[PROFILE::httpclass [HTTP::class] ts_enabled]So now I'm trying to determine how to access the other parameters of a specific HTTP class. If I have an HTTP class with the following configuration, how can I access the filters like hosts, paths, headers, etc?
profile httpclass asm_httpclass_01 {
defaults from httpclass
hosts "my_host"
paths "/class1"
headers "my_header"
cookies "my_cookie"
pool http_pool
asm enable
}I tried a few guesses, but wasn't able to parse anything:
[PROFILE::httpclass [HTTP::class] ts_uri]
[PROFILE::httpclass [HTTP::class] ts_uris]
[PROFILE::httpclass [HTTP::class] uri]
[PROFILE::httpclass [HTTP::class] uris]The wiki page for PROFILE doesn't show examples. And the new iRule editor (while very handy) doesn't have any auto-complete info for this.
And while we're at it, could you also detail what options there are for HTTP::class? I believe you can set the HTTP class using:
HTTP::class my_classbut are there other options as well?
Thanks,
Aaron
hoolioSo I was thinking about this further and realized it might be more appropriate to ignore the filters of the HTTP class and include the logic of which HTTP class to direct a request within the rule itself.
I tried the following, but found that you can't set the HTTP class using HTTP::class my_class:
when HTTP_REQUEST {
HTTP::class "test"
}
Error:
01070151:3: Rule [select_http_class_rule] error: line 3: [wrong args] [HTTP::class "test"]
So that leaves me with a couple of questions:
1. Is it currently possible to set the HTTP class within an iRule? If so, what is the correct syntax?
2. Is it possible to retrieve the attributes of an HTTP class with an iRule?
Thanks,
Aaron- From the documentation for the HTTP::class command (Click here) it seems that the HTTP::class command is read-only and returns the name of the HTTP::class associated with the given context. I don't currently see a way to query the class configuration data.
-Joe - Doh, I should have read your first post first... I'll look into what the valid arguments are for the PROFILE::httpclass command and let you know.
-Joe - The PROFILE:: commands only operate on the current profile. So, I would assume that it would return the value of any specified attribute of the currently selected HTTP class. Basically, leave out the HTTP class profile name in your example.
I'm not sure why you are trying to have the iRule select the HTTP class. These profiles were designed with the opposite behavior in mind. EG: The HTTP class would match criteria against the current request and then trigger the HTTP_CLASS_SELECTED event. - hoolioThanks for the information.
In general, I'd like to be able to use a rule to replace the filtering of the HTTP class and still send the request to ASM. Currently you can filter requests using an HTTP class by HTTP host header, URI, other HTTP headers, and cookies. I'd like to be able to add more logic to which requests get sent to which HTTP class (and the corresponding ASM policy), using a rule.
For this specific situation, I'm trying to workaround an issue whereby only the first 13 HTTP classes are used (C275423-1). The issue has been escalated, but I was hoping to get around the limitation using a rule to select which HTTP class to send the requests to.
So would it be possible to add the ability to set the HTTP class in a future release? I think it would be consistent with the functionality rules provide.
Thanks,
Aaron - You don't need to actually select a class to make this work. If you look at the _ASM_clientside rule, all you really need to do is replicate the code that happens in the HTTP_CLASS_SELECTED event.
So, what I would probably do is make two HTTP classes (one with ts_enabled, but that won't actually match anything - this is needed to properly configure the virtual for routing to ASM) and then another class that actually matches everything but does not have ts_enabled (it must have ts disabled so that your replacement rule will function correctly with the _ASM rules). Then create a rule that copies just the HTTP_CLASS_SELECTED event from the ASM clientside rule. Add your selection logic to the top of that event and sets tmm_ts_httpclass_selected to 1 or 0 depending on whether you want to go through ASM or not. Then replace the first "if {[PROFILE::httpclass [HTTP::class] ts_enabled] == 1}" check with a simpler "if {$tmm_ts_httpclass_selected}" check (which now bases the decision to route to ASM on the logic you just added to the top of the rule. That should be it.
Good luck. - hoolioGreat. Thanks for the tips. I'll test it out.
Aaron
