For the most part, multiple iRules on the same VIP are all executed regardless of what happens in previous ones. The obvious exceptions to this I can think of are HTTP_RESPONSE not running if the request is responded to in HTTP_REQUEST or if you explicitly disable events using 'event disable'.
One issue you might have is that most HTTP commands (like HTTP::path, HTTP::uri, etc) are cached in the same event and event priority. So if you log the HTTP::path value, modify it and then log it again, the change is not shown. You could just save the modified value of HTTP::path and reference that instead though. Or you could add subsequent code to another HTTP_REQUEST event with a higher priority that would run after the first rule. But I think using a variable in one HTTP_REQUEST event is probably easier.
This demonstrates the caching of the HTTP::path value
when HTTP_REQUEST {
log local0. "(priority 500) Current \[HTTP::path\] value [HTTP::path]"
HTTP::path "/new_path"
log local0. "(priority 500) Current \[HTTP::path\] value [HTTP::path]"
}
when HTTP_REQUEST priority 501 {
log local0. "(priority 501) Current \[HTTP::path\] value [HTTP::path]"
}
Here is a workaround for using one HTTP_REQUEST event:
when HTTP_REQUEST {
set path [HTTP::path]
log local0. "Current \$path value $path"
set path "/new_path"
HTTP::path $path
log local0. "Current \$path value $path"
}
Aaron