Forum Discussion
Hi Newf5learner,
as Odaah has already pointed out, the problems you're facing will be most likely commming from an unappropiate test environment (aka. unpredictable Keep-Alives from your browser)...
When I develop/troubleshoot iRules I'll alway use a HTTP debugging Forward Proxy (e.g. Fiddler, HTTPWatch) with settings to "Disable Keep Alive" for the connection between my client and the virtual server to get sure that any of my changes are getting active on the very next request.
If you can't use such debugging tools, then I would recommend to insert a Connection: Close HTTP header within the HTTP_RESPONSE or HTTP_RESPONSE_RELEASE events. This will also stop Keep-Alive sessions...
when HTTP_RESPONSE_RELEASE {
HTTP::header replace "Connection" "Close"
}
And if you're interested to even bypass the behavior of SOL13253 you could use a special crafted syntax to become able to apply iRule changed on active connections.
when RULE_INIT {
set static::dynamic_code {
Changes to this code will have an instant effect on existing connections..
log local0.debug "Try to change me!"
}
}
when HTTP_REQUEST {
if { $something } then {
Changes to this code will affect only new connections as discribed in SOL13253.
log local0.debug "Try to change me!"
}
The command below calls TCL code out of a global variable.
eval $static::dynamic_code
The command below calls TCL code out of a TCL procedure.
eval [call dynamic_code]
}
proc dynamic_code {
return {
Changes to this code will have an instant effect on existing connections..
log local0.debug "Try to change me!"
}
}
Note: A VE of LTM is as trustworthy as using a LTM applicance. 🙂
Cheers, Kai