Manipulate a HTTP:path then continue to parse iRule

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