Replacing packet payload contents

*Note:    While this rule is still technically correct, and can provide needed functionality in certain cases, we strongly recommend the use of the Stream profile now available on LTM as it provides this type of functionality within the product's configuration options, as well as circumventing some of the issues involved when applying an iRule such as the one below.*

Through the use of iRules you can reach into the packet mid-stream and affect many different aspects of the traffic passing through your BIG-IP. One of the ways in which this can be done is by the direct modification of packet information.
 

    Depending on the information you’re altering this can be very straightforward, with already built in commands, such as HTTP::header replace, or a bit more involved.

    Here is an example of one way that a rule could read into a response to find a specific piece of information and replace it regardless of whether or not there’s a command specifically designed to alter it.

when HTTP_REQUEST {
  # Don't allow data to be chunked
  if { [HTTP::version] eq "1.1" } {
    if { [HTTP::header is_keepalive] } {
        HTTP::header replace "Connection" "Keep-Alive"
    }
    HTTP::version "1.0"
  }
}

when HTTP_RESPONSE {
  # First, check to see if there's a Content-Length header
  if {[info exists [HTTP::header Content-Length]] } {
    # If there is, we'll collect that much data
    set clen [HTTP::header "Content-Length"]
  } else {
    # Otherwise we collect the max
    set clen 4294967295
  }

  if { $clen > 0 } {
    HTTP::collect $clen
  }
}

when HTTP_RESPONSE_DATA {
  # Here you define what you want to find in the payload
  set find "Bad_Data" 

  # And here's what you'll be replacing it with
  set replace "==ReWritten_Data_GOOD=="

  set payload [HTTP::payload]

  # Run the regsub to make all the replacements (add -nocase for case insensitivity)
  if {[regsub -all $find $payload $replace new_response] > 0} {
    HTTP::payload replace 0 [HTTP::payload length] $new_response
  }
}

This same concept would work on most connections, and for requests as well as responses, making the possibilities quite broad. Just one more example of the flexibility of iRules.