This event is triggered after ASM finished processing the request and found all violations of the ASM policy, if there were any, and before enforcing the action on the request, either forwarding to the server or responding with a blocking page. In case the of 100-Continue response, the event will be triggered after the body of the request was received by the ASM. This event replaces the ASM_REQUEST_VIOLATION event which is kept for backward compatibility. The iRules developer can check whether there have been violations using the ASM::status command.


  set x [ASM::violation_data]

  for {set i 0} { $i < 7 } {incr i} {
      switch $i {
      0         { log local0. "violation=[lindex $x $i]" }
      1         { log local0. "support_id=[lindex $x $i]" }
      2         { log local0. "web_application=[lindex $x $i]" }
      3         { log local0. "severity=[lindex $x $i]" }
      4         { log local0. "source_ip=[lindex $x $i]" }
      5         { log local0. "attack_type=[lindex $x $i]" }
      6         { log local0. "request_status=[lindex $x $i]" }


   if {([lindex $x 0] contains "VIOLATION_EVASION_DETECTED")}
      log local0. "VIOLATION_EVASION_DETECTED detected, uri=[HTTP::uri]"
      HTTP::header insert header_1 value_1
      ASM::payload replace 0 0 "1234567890"
   } else {
      log local0. "violation=[lindex $x 0]"
      log local0. "Decided to route is to different pool"
      HTTP::uri /index.php
      pool phpauction