Objective 3.02 on the 301a blueprint is all about profiles. Profiles are ubiquitous on a BIG-IP system, they contain all the knobs to turn to control the behaviour of traffic as it flows through the system. This is the first of several posts that will look at all things profiles on the BIG-IP system.

Stream Profile

This post will look at the Stream profile. The Stream profile is all about modifying the content of the data as it flows inbound from client to server, and outbound from server back to the client, through the BIG-IP system.

As with most profiles, you can configure this via the GUI or CLI, making use of the built-in profile functionality. Alternatively you can use an iRule using the STREAM command. Why would you choose one over the other? Using an iRule is always going to offer extreme flexibility and Stream is no exception. Via an iRule, you can go to town with a regular expressions that allow you to be granular with your matching patterns.

The Stream profile comes with a few caveats:

• If you apply the Stream profile to a virtual server without a HTTP profile, and only a TCP profile, you are able to do a match & replace of the entire data portion of the TCP segment, that is, both the HTTP headers & the payload itself.
• If you apply the Stream profile to a virtual server with a HTTP profile you are restricted to match & replace on the HTTP payload only.
• If the back-end server performs compression this prevents the BIG-IP system from being able to read the content. By creating a custom HTTP profile and removing the Accept-Encoding header you can remove the instruction to the server to compress the data.

The following are simple examples of how you can use Stream to modify the content both in the header and the payload.

Configuration

Configuration of the Stream profile via the GUI is done by going to Local Traffic  ››  Profiles : Other : Stream & clicking Create.

You'll be presented with two fields that you can populate:

• Source: This looks at the string sent by the client that we wish to rewrite.
• Target: This specifies the string used to rewrite the source string.

Using the above diagram we can amend the headers using the following configuration. Important! The values you enter here are case-sensitive:


Now if we test the above we see the headers being modified from the client (10.128.3.1) to the back-end server (10.128.2.170):


Remember, modification of the HTTP headers is only possibly when no HTTP profile is applied. If I were to add a HTTP profile to the virtual server and attempt the connection again, the LTM would pass through the headers unmodified:


To amend the payload we would do something similar:


Now if we test we should see the payload amended:


Hold on a minute, this isn't right. We should expect to see the word 'Everybody' instead. If we go back to the caveats we see that we need to ensure that the back-end server does not compress the data. As it stands all requests to my server contain the Accept-Encoding header. We need to create a custom HTTP profile to remove this Request Header and apply this to the virtual server:

Now let's try again:


Success!

There is another way of doing things. The above example can actually all be done within the Target field completely. You can achieve this by making use of delimiters to separate out the replacements using the following syntax in the Target field of the profile:

@<search string1>@<replacement string1>@ @<search string2>@<replacement string2>@

This now allows you to replace multiple strings within a response. So, let's say that we now wish to replace multiple strings where the original response body contains the strings "Hello World! Get the man a beer!". We want to replace the response strings thus:

• World! -> Everybody!
• Beer -> Pepsi

We can configure the following in the profile:

ltm profile stream LAB-STREAM-PROFILE {
    app-service none
    defaults-from stream
    source none
    target "@World!@Everybody!@ @beer@Pepsi@"
}

I've shown the CLI config as the GUI form field is too small to show everything.

Now when we test, although the back-end server will respond to the LTM with "Hello World! Get the man a beer!" the Stream profile will replace the words as above:

Real World Examples

It's all well and good providing simple examples of how the Stream profile works but the question is how you use this in a real-world scenario. This DevCentral resource page (login required) provides some good examples of how Stream can be used.

An example would be to remove the 'Server' response header to help obfuscate the web server type as a measure of security. Whilst this can be performed at the server level, it is not always done.

Summary

The Stream profile is a handy little tool to easily replace data between the client and server without the need for any involvement of the development team. Or rather to provide a quick fix until the back-end application is updated.