Forum Discussion
David_Noonan_67
Nimbostratus
NimbostratusWould this rule cause user problems?
I want to use HSL to log connections but I want one URI to get a slightly modified log entry. I can up with this modification of a working rule. The original logged on SERVER_CONNECTED but that didn't seem to let me access HTTP:uri, hence the change to HTTP_REQUEST.
I'm under the impression that if I don't include a redirect or rewrite or do anything to the traffic then it should do the logging in the irule and proceed with it's normal operation. Is that incorrect?
About 4-5 minutes after I applied the iRule the servers apparently showed down. I've since learned that the tests failing were both going to the VIP and going directly to the server (bypassing the irule) but before we put the rule back I have to validate that it wasn't the source of the problem.
Thanks
when HTTP_REQUEST {
set HSL [HSL::open -proto UDP -pool syslog-pool]
set FrontEnd "[IP::client_addr]:[TCP::client_port] <-> [clientside {IP::local_addr}]:[clientside {TCP::local_port}]"
set BackEnd "[IP::local_addr]:[TCP::local_port] <-> [serverside {IP::remote_addr}]:[TCP::server_port]"
set Uri [HTTP::uri]
if {$Uri equals "/foobar/foobarweb/login.aspx"} {
HSL::send $hsl "<190> HSL: FooBar: $FrontEnd | $BackEnd"
}
else {
Log connection details as local7.info; see RFC 3164 Section 4.1.1 - "PRI Part" for more info
HSL::send $HSL "<190> HSL: $FrontEnd | $BackEnd"
}
}
David_Noonan_67The iRule below is also applied to that VS but I don't think the two conflict (unless it's bad to have multiple HTTP_REQUEST events being called.
when HTTP_REQUEST {
set fqdn_name [HTTP::host]
}
when HTTP_RESPONSE {
if { [HTTP::is_redirect] }{
if { [HTTP::header Location] starts_with "/" }{
HTTP::header replace Location "https://$fqdn_name[HTTP::header Location]"
} else {
HTTP::header replace Location "[string map {'http://' 'https://'} [HTTP::header Location]]"
}
}
}- David_Noonan_67Anyone? I'm just looking for confirmation that there's nothing in that irule combination that would interrupt traffic.
Thanks 
Brian_69413I am not familiar with HSL, but theoretically no logging statements should interfere with user traffic. I do think it is bad practice to use variable names that coincide with functions. I have used multiple iRules with HTTP_REQUEST events, but I have never seen anything official on whether that is OK.
hooleylistCirrostratus
Hi David,
A server hasn't been selected in HTTP_REQUEST so you can't access the server IP in that event. I'd move the HSL::send command to SERVER_CONNECTED and save the values you need for any HTTP request command values to local variables in HTTP_REQUEST.
Here's an example:when CLIENT_ACCEPTED { set hsl_conn [HSL::open -proto UDP -pool syslog-pool] } when HTTP_REQUEST { set FrontEnd "[IP::client_addr]:[TCP::client_port] <-> [clientside {IP::local_addr}]:[clientside {TCP::local_port}]" set Uri [string tolower [HTTP::uri]] } when SERVER_CONNECTED { set BackEnd "[IP::local_addr]:[TCP::local_port] <-> [serverside {IP::remote_addr}]:[TCP::server_port]" if {$Uri equals "/foobar/foobarweb/login.aspx"} { HSL::send $hsl_conn "<190> HSL: FooBar: $FrontEnd | $BackEnd" } else { Log connection details as local7.info; see RFC 3164 Section 4.1.1 - "PRI Part" for more info HSL::send $hsl_conn "<190> HSL: $FrontEnd | $BackEnd" } }
Also, you could add logic to your HTTP redirect rewriting rule to handle a null or non-existent host header. You could set some default value if it's not present in the request.
The two iRules should work find on the same virtual server.
Aaron- David_Noonan_67Thanks, Aaron. I'll rewrite the iRule per your suggestions. Is there a guide/tutorial explaining BIG-IP events? I'm thinking of the order they happen and how to write scripts that cross events.
Brian,
I agree on the variable naming and don't remember why I did it that way since in other rules I've at least done something like "vUri" to distinguish the variable. I was probably in a hurry and willing to pay for it later. :-) (more likely not thinking about later) - hooleylistHere is a post with info on events:
http://devcentral.f5.com/Community/GroupDetails/tabid/1082223/asg/50/aft/24619/showtab/groupforums/Default.aspx24622
Very loosely, the HTTP:: commands are only available in HTTP events. Server related commands like IP::server_addr and TCP::server_port won't work until a serverside connection has been established in the SERVER_CONNECTED event.
Aaron