What is HTTP Part IX - Policies and iRules

In the previous article of this What is HTTP? series we covered optimization techniques in HTTP with compression and caching. In this article we pivot slightly from describing the protocol itself to showing ways to interact with the HTTP protocol on BIG-IP: policies and iRules. There is a plethora of content on DevCentral for how and what policies are, so rather than regurgitate that here, we’ll focus on what you can do with each approach and show a couple common examples. Before we do, however, run (don’t walk!) over to Chase Abbott’s To iRule, or not to iRule: Introduction to Local Traffic Policies article and Steve McCarthy’s LTM Policy article and read those first. Seriously, stop here and read those articles!

Example 1: Simple HTTP Redirect

I haven’t performed any advanced analysis on our Q&A section in quite a while, but at one time, redirection held the lion’s share of questions, and I still see them trickle in. Sometimes an application owner will move resources from one location to another within the app, either because the underlying platform has changed or navigation or site map redesign has occurred. Alternatively, the app owner may just want some vanity or random URLs to surface in advertisements so it’s easier to market and track demographically. To reorient application clients to the new resource locations, you can simply rewrite the URL before sending to the server, which will be unnoticed by the client, or you can redirect them to the new resource, which results in an HTTP response to the client and a second request for BIG-IP to handle the request for the “right” resource.

The 300 level status codes are used by the “server" to instruct the client on necessary additional actions. The two primary redirection codes are 301, which instructs the client that the resource has been moved permanently, and the 302, which instructs the client that the move is temporary.

For this example, we’re going to create a vanity URL to temporarily redirect clients from /http to this series landing page at /articles/sid/8311.

Policy Solution

Each policy has one or more rules. In this policy, we just need the one rule that has the condition of /http as the path and the action of redirecting a matching condition to the specified URL.

ltm policy simple_redirect {
    controls { forwarding }
    last-modified 2017-12-14:23:22:51
    requires { http }
    rules {
        vanity_http {
            actions {
                0 {
                    http-reply
                    redirect
                    location https://devcentral.f5.com/s/articles/sid/8311
                }
            }
            conditions {
                0 {
                    http-uri
                    path
                    values { /http }
                }
            }
        }
    }
    status published
    strategy first-match
}

Writing policies textually can be a little overwhelming, but you can also configure them in the GUI as shown below. Note that in version 12.1 and later, you need to publish a policy before it can be used, and altering policies requires making a draft copy before activating any changes.

iRules Solution

The iRule solution is actually quite short.

when HTTP_REQUEST {
  if { [HTTP::path] eq "/http" } {
    HTTP::redirect "https://devcentral.f5.com/s/articles/sid/8311"
  }
}

While short and simple, it is not likely to be as performant as the policy. However, since it is a very simple iRule with little overhead, the performance savings might not justify the complexity of using policies, especially if the work is being done on the command line. Also of note, if the requirement is a permanent redirect, then you must use an iRule because you cannot force a 301 from a policy alone. With a permanent redirect, you have to change the the HTTP::redirect command to an HTTP::respond and specify the 301 with a location header.

when HTTP_REQUEST {
  if { [HTTP::path] eq "/http" } {
    HTTP::respond 301 Location "https://devcentral.f5.com/s/articles/sid/8311"
  }
}

There is a way to use a policy/iRule hybrid for 301 redirection, but if you need the iRule from the policy, I'd recommend just using the iRule approach.

Example 2: Replace X-Forwarded-For with Client IP Address

Malicious users might try to forge client IPs in the X-Forwarded-For (XFF) header, which can potentially lead to bad things. In this example, we’ll strip any XFF header in the client request and insert a new one.

Policy Solution

In this policy, we don't care what the conditions are, we want a sweeping decision to replace the XFF header, so no condition is necessary, just an action. You'll notice the

tcl:

immediately before using the iRules

[IP::client_addr]

. These tcl expressions are supported in policies, and are a compromise of performance for additional flexibility.

ltm policy xff {
    last-modified 2017-12-15:00:39:26
    requires { http }
    rules {
        remove_replace {
            actions {
                0 {
                    http-header
                    replace
                    name X-Forwarded-For
                    value tcl:[IP::client_addr]
                }
            }
        }
    }
    status published
    strategy first-match
}

This works great if you have a single XFF header, but what if you have multiples? Let's check wireshark on my curl command to insert two headers with IP addresses 172.16.31.2 and 172.16.31.3.

You can see that one of the two XFF headers was replaced, but not both, which does not accomplish our goal. So instead, we need to do a remove and insert in the policy like below.

ltm policy xff {
    last-modified 2017-12-15:00:35:35
    requires { http }
    rules {
        remove_replace {
            actions {
                0 {
                    http-header
                    remove
                    name X-Forwarded-For
                }
                1 {
                    http-header
                    insert
                    name X-Forwarded-For
                    value tcl:[IP::client_addr]
                }
            }
        }
    }
    status published
    strategy first-match
}

Removing and re-inserting, we were able to achieve our goal as shown in the wireshark output from the same two IP address inserted in XFF headers from a curl request.

iRules Solution

The iRule is much like the policy in that we’ll remove and insert.

when HTTP_REQUEST {
  HTTP::header remove "X-Forwarded-For"
  HTTP::header insert "X-Forwarded-For" [IP::client_addr]
  # You could also use replace since it will insert if missing
  # HTTP::header replace "X-Forwarded-For" [IP::client_addr]
}

Again, short and sweet! Like the policy example above, using

HTTP::header remove

in the header command removes all occurrences of the XFF header, not just the last match, which is what

HTTP::header replace

does.

Profile Solution

This is where we step back a little and evaluate whether we need an iRule or policy at all. You might recall from part five of this series the settings in the HTTP profile for the X-Forwarded-For header. But with that, I noted that enabling this just adds another X-Forwarded-For header, it doesn’t replace the existing ones. But a slick little workaround (much like our policy solution above, but completely contained in the http profile!) is to add the header to the remove and insert fields, with the values set as shown below.

Keep in mind you can only erase/insert a single header, so it works for this single solution, but as soon as you have more parameters the policy or iRule is the better option.

Profiles, Policies, and iRules…Where’s My Point of Control?

This isn’t an HTTP problem, but since we’re talking about solutions, I’d be remiss if I didn’t address it. Performance is a big concern with deployments, but not the only concern. One other big area that needs to be carefully planned is where your operational team is comfortable with points of control. If application logic is distributed among profiles, policies, and iRules, and that changes not just within a single app but across all applications, there is significant risk for resolving issues when they do arise if documentation of the solutions is lacking. It’s perfectly ok to spread the logic around, but everyone should be aware that XYZ is in iRules, ABC is in policies, and DEF is in profiles. Otherwise, your operations teams will spend a significant amount of time just mapping out what belongs where so they can understand the application flow within the BIG-IP!

I say all that to drive home the point that all iRules is an ok solution if the needs policies address is a small percentage of the overall application services configured on BIG-IP. It’s also ok to standardize on policies and push back on application teams to move the issues policies can’t address back into the application itself. The great thing is you have options.