Headers Versus Content: The Highest-End Feature in Load Balancing

When it comes to functionality, one of the greatest differentiators between different load balancing products is the ability to read or manipulate HTTP headers and HTTP content.

Virtually every load balancing product — from the inexpensive value-market load balancers to the six-figure Enterprise market devices — have the ability to read and manipulate HTTP headers. Cookie-based persistence is one such feature that is based on the ability to read and manipulate HTTP headers.

There are some load balancers (typically the Enterprise-marketed designs) that in addition to reading and manipulating HTTP headers also have the ability to view and manipulate HTTP content.

HTTP 101

Every object requested through HTTP, each individual JPG, HTML, Flash file, etc., has it’s own HTTP request which always includes an HTTP request header. Sometimes, the request also has content, such as with an HTTP POST on a HTML form.

The response from the server also always includes an HTTP response header, and in most cases includes HTTP content, which would be the requested object (JPG, HTML, etc.). (There is a case where the HTTP server would only include a header and no content, and that’s with an HTTP HEAD request.)

Being fluent in HTTP headers is the basis behind cookie-based persistence, as well as URL/web switching. So why would you want to mess with HTTP content? One common example is with HTTPS. If you use a load balancer to terminate HTTPS, and forward the traffic to real servers unencrypted, the real servers will operate as if they’re only HTTP. This means when they generate a link, they will typically generate it with an “http://” prefix. When a user clicks on that link, they will hit the load balancer on the HTTP port, not the HTTPS port. A load balancer that can manipulate content, however, can change the references to “http://” in the content to “https://” before the HTTP response is sent to the client. The servers and clients are none-the-wiser.

Beyond simple HTTP/HTTPS search and replace, you need a control language in order to fully manipulate HTTP content. For that, F5’s LTM (perhaps better known from its old name, BIG-IP) has its venerable iRules. A few other vendors, such as A10 Networks, have their own control language for manipulating HTTP content (in their case, it’s called aRules).

The benefit of these control languages and the ability to manipulate HTTP content is that you can have a good deal of control and flexibility with content. The disadvantage is that you can have a good deal of control and flexibility with content. With great power comes great obfuscation of the roles of a network admin/application developer. The skillsets tend to be fairly different, and it does require a unique approach to network administration and application development when the line between the two are muddied.

When manipulating HTTP content, the load balancer/ADC is doing more work than it would be if it were just operating in Layer 4, or operating at Layer 7 and only looking at headers. As such, total capacity for a load balancer/ADC would be lower when manipulating HTTP content. Also, because the degree to which the HTTP content is manipulated can vary quite a bit, there’s no hard and fast rule as to how much of the overall capacity of the device would be affected. It could be very little, or with a lot of control logic (or badly written control code), it could be very significant.

Manipulating HTTP content can give you a great deal of flexibility in how you deploy your site. Other than perhaps overall capacity, it’s the highest-end feature available in load balancing/ADC, and it’s only supported by a few vendors. And because it means you’re no longer just a packet-slinger, you should have a fairly good idea of what you want content manipulation to accomplish, and who supports the endeavors.