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.


  # 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"

  # 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

  # 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.

Published Aug 30, 2005
Version 1.0

Was this article helpful?

1 Comment

  • It would make sense to restrict the collection to specific request filetypes ([HTTP::path] ends_with ".asp") or to check the response Content-Type header to make sure you don't bother collecting binary content.



    Another significant benefit of using a STREAM::expression is you don't have to restrict the server side connection to HTTP 1.0.